This patch only fixes warning, not changing actual behavior of editor.
HTMLEditRules::ReturnInParagraph() splits paragraph *around* given point.
Therefore, from point of view of caller, offset of setting point may be
invalid after HTMLEditRules::ReturnInParagraph() handled the edit action.
In this case, invalidating stored child of the point may cause warning
since offset may be larger than length of its container.
So, if HTMLEditRules::ReturnInParagraph() handles the edit action,
the caller, HTMLEditRules::WillInsertBreak(), should cancel invalidating
the stored child for avoiding unnecessary warning.
MozReview-Commit-ID: DKJlr0Awwlo
--HG--
extra : rebase_source : 8fbefff3b46e55daf8db6342f00de904315d7fcc
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : 6cab2e6e7b4ba8cfb56d8320be24ca4afcbe55fb
extra : amend_source : 1d8c59086a9158a49dd270b64ecf8341ed4002ce
Before bug 1425091, we called RangeUpdater::SelAdjCreateNode() with point of
new node in EditorBase::CreateElement(). However, it was accidentally changed
to point *in* new element. Therefore, setting such DOM point causes warnings
in debug build and call of RangeUpdater::SelAdjCreateNode() must be failed
since the point stores wrong container node.
Additionally, this patch stops using another EditorRawDOMPoint instance which
is just redundant and renames |ret| to |newElement| for making its meaning
clearer.
MozReview-Commit-ID: Gc0YgaNLYcx
--HG--
extra : rebase_source : c2fbe2669ca8a5993e26b357f53dc38341fd6bf6
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : b89698f4ab56fdd97a4cd8c515a8b33f6a74a7af
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
Part 1. changes to static method, so caller should use scope operator instead
of mCSSEditUtils member.
MozReview-Commit-ID: GlCfyjlQgr0
--HG--
extra : rebase_source : f558fc833d5f3cb193a543fc1b05cdeb58f60ec1
extra : histedit_source : 741529204d2dddef0f2dab9e18055186155eca8f
Some methods in CSSEditUtils can change to static methods or const method.
So we should change to it to avoid unnecessary HTMLEditor check.
MozReview-Commit-ID: IwAbeNsgqSr
--HG--
extra : rebase_source : 649f198a59e06504a9e54cb64ab942ce04854ad2
extra : histedit_source : f4506dbdf8f9ccb614aca8f84aff1d572f0ce37e
EditorDOMPointBase::RewindOffset() treats it as error when offset is
same as length of container. However, this is wrong because offset can
be same as length of its container since it means after the last child
or last character. So, if an instance points end of a container node,
Rewind() always fails unexpectedly.
MozReview-Commit-ID: A9bvsxETDoo
--HG--
extra : rebase_source : f05994f2924adaa29711da3916f431688eaa79b7
The following methods are unused in m-c, c-c and bluegriffon from JavaScript.
- selectionContainerAbsolutelyPositioned
- absolutelyPositionedSelectionContainer
- absolutePositionSelection
- relativeChangeZIndex
- absolutelyPositionElement
- setElementPosition
- getElementZIndex
- setElementZIndex
- relativeChangeElementZIndex
- showGrabberOnElement
- hideGrabber
So let't remove these method from IDL.
MozReview-Commit-ID: JASJmB65wR2
--HG--
extra : rebase_source : a7c3cdf0ea96ec7b81bed7573c57d6040033d01b
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
Since CheckSelectionStateForAnonymousButtons is called from selection listener,
We should reduce some QI for this.
MozReview-Commit-ID: 17hhupmnnV5
--HG--
extra : rebase_source : 81ed7f844033f75e5fcf1d8983a45804f0b9544f
The only C++ caller immediately QIs the result anyway, and the exact type
returned doesn't matter for JS callers because the return values are DOM
objects. This makes it simpler to rejigger the internals to work with nsINode
and Element and whatnot.
MozReview-Commit-ID: 863IDGECqYY