Commit Graph

8 Commits

Author SHA1 Message Date
Makoto Kato
8c5d5f7c30 Bug 1449147 - Clean up more nsIDOMNode usages in editor. r=masayuki
To reduce QI, I would like to replace nsIDOMNode with nsINode.  And some
parameters in *DataTransder.cpp's methods is unused (it uses as nullptr),
so we should remove these parameters.

Also nsIDOMNodeList is unused now, so we should remove this including.

MozReview-Commit-ID: 1QTIkxDazjJ

--HG--
extra : rebase_source : 3961e897fcaa96975facc822821f1e223cab358d
2018-03-27 20:19:35 +09:00
Boris Zbarsky
a6f9dbf34e Bug 1432944 part 6. Remove the nsIDOMNode overloads of HTMLEditUtils::IsNamedAnchor and HTMLEditUtils::IsTable. r=m_kato
MozReview-Commit-ID: 4KlppKdzJGy
2018-01-29 23:27:59 -05:00
Boris Zbarsky
423c0886df Bug 1432944 part 5. Remove the now-unused nsIDOMNode overload of HTMLEditUtils::IsLink. r=m_kato
MozReview-Commit-ID: CDnYK194JB9
2018-01-29 23:27:59 -05:00
Boris Zbarsky
4d88c28e4d Bug 1432186 part 17. Remove nsIDOMNode's parentNode attribute. r=mccr8
MozReview-Commit-ID: 4xzDwwEqnvE
2018-01-29 23:10:52 -05:00
Masayuki Nakano
36d48397f0 Bug 1408125 - part 4: Redesign HTMLEditor::InsertNodeAtPoint() with EditorRawDOMPoint r=m_kato
HTMLEditor::InsertNodeAtPoint() should take |const EditorRawDOMPoint&| as
an argument which specifies point to insert.  Additionally, it should take
|EditorDOMPoint*| to return the next point of actual insertion point.

Additionally, this patch renames it to InsertNodeAtProperAncestor() for
explaining what it will do.

MozReview-Commit-ID: HYUzSlyPxAd

--HG--
extra : rebase_source : 57033cdc4458b45a5fe9d6aa642c185133a79304
2017-11-28 22:28:07 +09:00
Masayuki Nakano
f802692190 Bug 1411687 - part 2: Rewrite the check to insert a <br> element in HTMLEditRules::WillInsertBreak() r=m_kato
Currently, HTMLEditRules::WillInsertBreak() checks if the editing host can
contain a <p> element as a child or a descendant.  However, this is not enough.
If an inline element has a block element which can contain a <p> element,
current implementation considers to insert a <br>.  This is possible when
* The editing host is an unknown element including user defined element.
* The editing host is an inline element and its children and/or descendants
  were added by JS.  E.g., <span contenteditable> element can have <div>
  element.

I think that we should consider to insert a <br> element when:
- There is no block ancestors in the editing host.
- The editing host is the only block element and it cannot contain <p> element
  or the default paragraph separator is <br> element.
- The nearest block ancestor isn't a single-line container declared in the
  execCommand spec and there are no block elements which can contain <p>
  element.

Note that Chromium checks if CSS box of ancestors is block too.  However,
it must be out of scope of this bug.

MozReview-Commit-ID: HdjU9t83Nd1

--HG--
extra : rebase_source : 7030671268a610613359b5d8ae5d126e120f59bd
2017-10-27 01:27:44 +09:00
Makoto Kato
2c1a2f9f2c Bug 1344116 - Clean up HTMLEditRules::RemoveAlignment. r=masayuki
Before I will fix some justify* command's bug, I would like to clean up HTMLEditRules::RemoveAlignment to get rid of nsIDOM* into this method.

MozReview-Commit-ID: 4UATycS5iBl

--HG--
extra : rebase_source : 7079a774b4b8359aeffbdbdf2efe0b45bd92c173
2017-03-03 13:13:21 +09:00
Masayuki Nakano
379230116b Bug 1260651 part.16 Rename nsHTMLEditUtils to mozilla::HTMLEditUtils (and their files too) r=mccr8
MozReview-Commit-ID: DABzQHszB0c

--HG--
rename : editor/libeditor/nsHTMLEditUtils.cpp => editor/libeditor/HTMLEditUtils.cpp
rename : editor/libeditor/nsHTMLEditUtils.h => editor/libeditor/HTMLEditUtils.h
2016-07-07 14:01:12 +09:00