We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
EditSubAction::ignore is declared for making HTMLEditRules::AfterEditInner()
ignores post-processing of handling edit action. Currently, this is used only
by TextEditRules::CreateBogusNodeIfNeeded() and
HTMLEditor::ReplaceHeadContentsWithHTML(). So, we should make them use
specific EditSubAction values which explain what they do and make
HTMLEditRules::AfterEditInner() ignore both of them.
MozReview-Commit-ID: JSHcgPfTrOE
--HG--
extra : rebase_source : c054c2db257dda7e1e3ace01f8e8831e07268f7e
According to this usage, perhaps, we can remove this from EditSubAction and
this should be moved to new EditAction.
MozReview-Commit-ID: HzfcC051rNB
--HG--
extra : rebase_source : e42cade8436b082b4dc2adfcbbac75e17779cfd7
And the odd number assign does not make sense anymore. So, removes it.
MozReview-Commit-ID: JSyMNcrNhpP
--HG--
extra : rebase_source : efdb31d94d0fcae50cd72b5ee0d27041a454887a
Although, there might be no reason to have those edit sub-actions separately.
MozReview-Commit-ID: BaaNCqfk4V4
--HG--
extra : rebase_source : 061bc85c85489b6b2617e05bd91254667ddedb1a
When we implement InputEvent.inputType, we need to set a stack class to record
which edit action is currently handled. However, currently, we call smaller
jobs as edit action. For example, when user types a character at selecting
some characters, then, EditAction::deleteSelection is performed first, then,
EditAction::insertText is performed. However, for the InputEvent.inputType,
we need inserText information. So, for making new enum EditAction, we need
to rename current EditAction to EditSubAction.
And also this renames related stuff:
EditorBase::mIsInEditAction -> EditorBase::mIsInEditSubAction
EditorBase::IsInEditAction() -> EditorBase::IsInEditSubAction()
EditorBase::mAction -> EditorBase::mTopLevelEditSubAction
TextEditRules::mTheAction -> TextEditRules::mTopLevelEditSubAction
EditorBase::StartOperation() ->
EditorBase::OnStartToHandleTopLevelEditSubAction()
EditorBase::EndOperation() ->
EditorBase::OnEndHandlingTopLevelEditSubAction()
AutoRules -> AutoTopLevelEditSubActionNotifier
RulesInfo -> EditSubActionInfo
MozReview-Commit-ID: cvSkPUjFm1
--HG--
extra : rebase_source : baf527a3e353b7a8ebe9a46be2243b059c500234
HTMLEditor has 2 type of public methods. One is rue-public methods. I.e.,
they should be able to be called by anybody. E.g., command handlers, event
listeners, or JS via nsIEditor interface. The other is semi-public methods.
They are not called by the above examples but called by other classes which
are helper classes to handle edit actions. E.g., TextEditRules, HTMLEditRules,
HTMLEditUtils, CSSEditUtils and Transaction classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make HTMLEditor have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in HTMLEditor.h
(except removes BlockTransformationType since it's unused and replaces
ResizingRequestID with new enum class ResizeAt since normal enum isn't hit by
searchfox.org).
MozReview-Commit-ID: 7PC8E8vD7w2
--HG--
extra : rebase_source : 13f51565f2b89ab816ba529af18ee88193a9c932
TextEditor has 2 type of public methods. One is true-public methods. I.e.,
they should be able to be called by anybody. E.g., command handlers, event
listeners, or JS via nsIEditor interface. The other is semi-public methods.
They are not called by the above examples but called by other classes which
are helper classes to handle edit actions. E.g., TextEditRules, HTMLEditRules,
HTMLEditUtils, CSSEditUtils and Transaction classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make TextEditor have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in TextEditor.h.
MozReview-Commit-ID: Db3H6d1V8IU
--HG--
extra : rebase_source : d928a6bb378d02944c5a207de83211c33bb63613
EditorBase (and other editor classes) have 2 type of public methods. One is
true-public methods. I.e., they should be able to be called by anybody.
E.g., command handlers, event listeners, or JS via nsIEditor interface.
The other is semi-public methods. They are not called by the above examples
but called by other classes which are helper classes to handle edit actions.
E.g., TextEditRules, HTMLEditRules, HTMLEditUtils, CSSEditUtils and Transaction
classes.
When we will implement InputEvent.inputType, we need to create new stack
class and create its instance at every true-public methods to manage current
inputType (like TextEditRules::AutoSafeEditorData). Therefore, it should not
happen that new code starts to call semi-public methods without the new
stack class instance.
For preventing this issue, we should make EditorBase have only the true-public
methods as public. The other public methods should be protected and their
users should be friend classes. Then, we can protect such method from external
classes.
Note that this patch just moves the methods without any changes in EditorBase.h
(except removes GetName() since there is no body of this method and removes
IterDirection since it's unused).
MozReview-Commit-ID: HBseKLL6pxx
--HG--
extra : rebase_source : 2251ff659d831d01a6778d38f4e2714fcf2d6ef4
HTMLEditRules::GetNodesFromPoint() uses ErrorResult only for checking in
debug build. So, it should use IgnoredErrorResult instead.
MozReview-Commit-ID: 5roQI03A0kF
--HG--
extra : rebase_source : 5f54dc18635653d214b22520f4747a00258d9d9b
This patch adds new rules of TextEditRules and HTMLEditRules about
NS_ERROR_EDITOR_DESTROYED.
Additionally, this patch moves some method explanation in each .cpp file to .h
file.
MozReview-Commit-ID: JqZFrWyrND8
--HG--
extra : rebase_source : d86385d9c26bb23adae1eca3b1be1a868c20e353
Additionally, it creates AutoSelectionRestorer. So, this patch adds
CanHandleEditAction() check after its caller since even if it returns
NS_OK, the editor might have been gone.
MozReview-Commit-ID: BgIbpHFFPE1
--HG--
extra : rebase_source : 010befdb34f8269f6f7fc24d1ae13eba4575aa69
And this patch creates a new method, OutdentAroundSelection(), to check if
restoring Selection with AutoSelectionRestorer causes destroying the editor.
However, this does NOT change any logic in the new method except changing some
else-if blocks to if blocks with early-return style.
MozReview-Commit-ID: JMIo4kUOkwx
--HG--
extra : rebase_source : 0d628ebb866d7b63f8b78e6d701c27378a82dfb6
And this patch renames it to SplitRangeOffFromBlockAndRemoveMiddleContainer()
for making the name explain what it does.
MozReview-Commit-ID: 546dnCeoGOV
--HG--
extra : rebase_source : 7f0762cfa377a07d28342a1092ad0a7ee70fa108
And this patch renames it to SplitRangeOffFromBlock() for making the name
explain what it does since "split" is used as splitting to two nodes widely
in editor.
MozReview-Commit-ID: GrRu5sI4yrP
--HG--
extra : rebase_source : 3ec27bce3769af518d3f1c317559fd89d379c539
Additionally, this patch renames it to MaybeDeleteTopMostEmptyAncestor() for
making its name explain what it does.
MozReview-Commit-ID: 1i7zeq9In2T
--HG--
extra : rebase_source : 8d9de9e6154038a993be636c3cedf950a6efd179
PromoteRange() related methods do not change Selection nor the DOM tree.
Therefore, they must be safe. However, only PromoteRange() takes an nsRange
instance and modifies it. If it's in Selection, that causes selectionchange
event. Therefore, we should check if given range is in Selection with
MOZ_ASSERT().
MozReview-Commit-ID: AXkmHFB4P08
--HG--
extra : rebase_source : 539b39d0217a7dc06f76e70546096d30b2734c02
Despite of the name of GetNodesForOperation() and related methods, it changes
the DOM tree if their aTouchContent is TouchContent::yes (by default).
Therefore, they should return NS_ERROR_EDITOR_DESTROYED if they cause destroying
the editor and all callers should check the result. Therefore, this patch mark
them as MOZ_MUST_USE.
Additionally, because of importance of aTouchContent, this patch makes the
arguments not optional. This change must make other developers being careful
to use them. (Although TouchContent does not feel dangerous. We should rename
it to make its risk clearer.)
On the other hand, this patch removes aTouchContent from
GetParagraphFormatNodes() since it's always called with TouchContent::no.
Therefore, this method is always safe.
Although I tried to document those methods, but I have not understood them
completely yet. Perhaps, we should redesign them in another bug both to
learn them and making them faster and simpler.
MozReview-Commit-ID: 4vknJGUdwEe
--HG--
extra : rebase_source : 486949005283548697e6eeb7175f6189a66defaa
Unfortunately, we need to make it take out argument for returning new first
child point of right node. If we can create JoinNodesResult which have
nsresult and EditorDOMPoint, we can avoid that, but EditorBase::JoinNodes()
does not want it. So, even if we create such class, only 2 callers of the
methods are its users...
MozReview-Commit-ID: 1zwVZ0FriwN
--HG--
extra : rebase_source : 1f7867774f9a30bec78596b0282717435e7223c0
And this patch renames it to
InsertBRElementToEmptyListItemsAndTableCellsInChangedRange().
MozReview-Commit-ID: 1DGhcI93YAk
--HG--
extra : rebase_source : caa675a5b02c18e9ca57171294bdaf48e7563dc0
And this patch renames it to RemoveEmptyNodesInChangedRange().
MozReview-Commit-ID: Kr2xmUOH1ZZ
--HG--
extra : rebase_source : 59a0a70360c6e0d426c329f4be757c2c0eac96c4
Additionally, this patch renames its specific enum class from ContentsOnly
to ResetAlignOf for making its target clearer.
MozReview-Commit-ID: KD4ndAsMClN
--HG--
extra : rebase_source : 302598397cf32893c7db18a6a014d0db862cb8f6
Additionally, this patch renames it to ChangeMarginStart() for making its
job clearer and add two inline wrapper methods.
MozReview-Commit-ID: L2GfLKhT6sa
--HG--
extra : rebase_source : d1d293f742214048ce5dfbbb7ebd50b0cbeed881
This patch also makes aCancel of TextEditRules::WillInsert() optional since
a lot of callers need to ignore the result.
MozReview-Commit-ID: JrvycxMQ9Mm
--HG--
extra : rebase_source : 9ecdc0fd363d9da33c12409f2993da9c58553598
This patch creates internal method for it as DeleteSelectionWithTransaction()
because it needs to create SelectionBatcher and destruction of it may cause
destroying the editor. Therefore, unfortunately, all callers of
DeleteSelectionWithTransaction() needs to check CanHandleEditAction()
manually. If we could use try-catch, we could make it safer, though.
MozReview-Commit-ID: 13enOQjEzNn
--HG--
extra : rebase_source : 5a902026bcc507fbf9f1949fdcf33a98aabd9a0b
And also this patch removes unnecessary arguments from the method.
MozReview-Commit-ID: UKscK4vFVX
--HG--
extra : rebase_source : 7f6b9405824a3f175f165a2d7d75a293108278f3
Note that HTMLEditRules::DocumentModifiedWorker() is a runnable method.
So, it cannot return nsresult. Therefore, it just checks the result
only with NS_WARNING_ASSERTION().
MozReview-Commit-ID: KBSpv5H5KGU
--HG--
extra : rebase_source : b356ab04d0459214df9dbb3dbfb0e3eecc686348
And also this patch marks it as MOZ_MUST_USE. All callers have to check if
the result is NS_ERROR_EDITOR_DESTROYED at least.
MozReview-Commit-ID: H4DfU1asPpe
--HG--
extra : rebase_source : c11cc00500aad44bd542147fb971e3cce4d634e2
First, this patch changes TextEditRules::CreateBRInternal() to a private method
for making any callers use CreateBR() or CreateMozBR() instead.
Then, this patch makes TextEditRules::CreateBRInternal() return both nsresult
and created <br> element with CreateElementResult class.
Finally, this patch makes all callers of them check if they don't return an
error code including NS_ERROR_EDITOR_DESTROYED.
MozReview-Commit-ID: 18OvPmbDVHK
--HG--
extra : rebase_source : 328a91146539763cec317105b92aa3ce5d4b8233
This patch defines NS_ERROR_EDITOR_DESTROYED error code as an editor module
specific error code.
And creates TextEditRules::CanHandleEditAction() to check if the instance
can keep handling edit action.
MozReview-Commit-ID: 4qECwNBO0yz
--HG--
extra : rebase_source : a925a9b6840d4d06e2792b9fe276e062288b0806
Now RulesInfo uses nsAString, but old comment is "XXX Struct should store
a nsAReadable*". We can remove unnecessary local variable of nsString.
MozReview-Commit-ID: C7gnTG7xTjU
--HG--
extra : rebase_source : e141bbcefd75d90b836668f710350d4362d66c76
CanPasteTransferable and PreDestroy aren't used from script (inc. comm-central
and bluegriffon), so we should move these to out of nsIEditor.
MozReview-Commit-ID: GRfBobAm2qi
--HG--
extra : rebase_source : 812792ff43da24bfd9cb99c4b3127e6acdc43ba1
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
Some Did*() of TextEditRules and HTMLEditRules do nothing except returning
NS_OK. Let's remove them since there is no reason to keep them.
MozReview-Commit-ID: Jcdh5rnm5Yc
--HG--
extra : rebase_source : 54aedd8187edfa244bc8fbe8f560fb6ee064e9cf
Now, each protected/private method of TextEditRules and HTMLEditRules can
retrieve Selection instance safely and quickly. Therefore, their pointer or
reference of Selection arguments are not necessary. Therefore, this patch
removes them.
MozReview-Commit-ID: 1SPmKXmd7kz
--HG--
extra : rebase_source : 32dfd2d5e8b0667318a5b3766a8a7d8594bba8e7
After this patch applies, most methods of TextEditRules and HTMLEditRules
don't need to take Selection as their arguments. Therefore, next patch will
remove them.
MozReview-Commit-ID: 99r3ZkfG2In
--HG--
extra : rebase_source : 8666ded8f2e6954f2e3cf6bb1ba1cf3313f65e70
Although, this patch removes first check of mHTMLEditor in each method. If
this causes some security issues, we should add now. However, automated
tests don't indicate it.
Anyway, it should be fixed by bug 1454900 in same cycle.
MozReview-Commit-ID: 3LAtOQHyR5J
--HG--
extra : rebase_source : 48b78cb9477c6c47d23a864404ce95ca9edb8588
This patch adds a debug methods to check if AutoSafeEditorData as expected and
inserting top of each method whose mTextEditor is replaced with TextEditorRef().
MozReview-Commit-ID: 8yjHsypLMRx
--HG--
extra : rebase_source : 0c07d18d102d6ffe6f4bc0cf50ad0dfca1f8bd4d
Except HTMLEditRules::WillJoinNodes(), observer methods of HTMLEditRules
accesses mHTMLEditor. Therefore, we need to make them create AutoSafeEditorData
instance in the stack.
Note that for reducing EditorBase::GetSelection() calls, this patch adds
Selection& argument to all of them.
MozReview-Commit-ID: 6mjuD2gZwVp
--HG--
extra : rebase_source : 56f16747a80927f0477b9b54f6088be719ed7b01
This patch creates a stack class in TextEditRules, its name is
AutoSafeEditorData and make all public methods (except editor observer methods)
which may change DOM tree, fire some DOM events or calling some XPCOM listeners
create its instance in the stack. Then, it grabs associated editor instance
and its selection instance.
Next patch will make remaining public methods create AutoSafeEditorData.
MozReview-Commit-ID: 8oshdhL3ONQ
--HG--
extra : rebase_source : 591db71e45fe28ca93cbebd9bb7da8c16eae4466
SplitNodeDeepWithTransaction will split nodes until better point. But
this test case becomes that node is orphan into loop. So I would like to
add more check whether parent is nothing.
MozReview-Commit-ID: EroSV4uVBVL
--HG--
extra : rebase_source : f594bdf7cd9efac7d10e6e05a8f87dadfc761295
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
Gecko has some built-in UIs:
* to edit size of objects like <img>, <table> and absolute positioned elements.
* to edit position of absolute positioned elements.
* to add/remove table columns and rows.
Currently, those UIs are available in both designMode editor and contenteditable
editor only on Gecko. I.e., the other browsers' users cannot modify as such
without web apps implement such function. So, for compatibility with the
other browsers, we should hide those UIs by default. On the other hand, if
this is too risky for backward compatibility, we should not do that.
So, before doing that, we should collect actual usage data of object resizers,
inline table editing UI, positioning UI of absolute positioned elements with
telemetry probes.
This patch adds 3 sets of probes for each UI. One is percentage of showing
each UI in all instantiated HTMLEditor. The other is number of user interaction
of each UI in HTMLEditors which has shown the UI.
This patch makes all new probes as "opt-out" because they are really important
data since used for deciding whether those UIs are necessary or unnecessary.
MozReview-Commit-ID: B9Y6GTiCPw6
--HG--
extra : rebase_source : 00e49f31712e24cb269ad3aa65c7d13b7cccb3a5
Use fatal MOZ_ASSERT or non-fatal NS_ASSERTION instead.
MozReview-Commit-ID: 1QAsgoWpXDn
--HG--
extra : source : 9ca972b6b3e7d3b576e20a0bf412df51d82aad9f
extra : intermediate-source : a909a9d7bc9a53095e963a4bea45f4fc4aa85b72
It is unnecessary to keep virtual method for
mozInlineSpellChecker::SpellCheckAfterEditorChange, so we should remove virtual
keyword.
MozReview-Commit-ID: 2ry5uhMTFVC
--HG--
extra : rebase_source : ba86bb7c4e47598f83e3869733a238a740cef6b2
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
The patch is a bit large because all these methods except
SswitchTableCellHeaderType call each other; doing it piecemeal would have
required introducing, then removing, a bunch of QIs.
Currently, EditorBase handles most composition events. However, only
eCompositionChange event handler is in TextEditor and it's the main event
of handling composition. Therefore, we should make all composition event
handlers in one place for easier to read, and make them non-virtual.
MozReview-Commit-ID: BYDhiPyGKvo
--HG--
extra : rebase_source : ed9db0f49d7ae268c85359e48015e86584f9c999
This is simple mistake of bug 1451672.
EditorBase::CloneAttributesWithTransaction() sets both sourceElement and
destElement to aDestElement, but of course, it should set sourceElement to
aSourceElement.
Additionally, this patch adds mozilla specific web-platform tests to check
attribute cloning with basic edit operation.
MozReview-Commit-ID: GM1VjRHG7C3
--HG--
extra : rebase_source : 95427853442454525232df519ce5b5ad7bb12693
No one uses outputToStream even if c-c and BlueGriffon. We should remove this.
MozReview-Commit-ID: LEUtfc89DBe
--HG--
extra : rebase_source : f0c5aa918f577ca8a285afd2414fe3da6545fefc
No one uses postCreate from script even if c-c and BlueGriffon. So we should
devirtualize this
MozReview-Commit-ID: D3FKVEvG7Go
--HG--
extra : rebase_source : 9915a93ea8ae18bee251507a4c94fe66c0f03d0f
No one uses syncRealTimeSpell from script even if c-c and BlueGriffon. So
we should devirtualize this
MozReview-Commit-ID: AoOb165dOFa
--HG--
extra : rebase_source : e1a9dcdfa6cfe6c918a06a2738c38a6cb9441a1d
HTMLEditor::InsertElementAtSelection() doesn't check if selection is in
native anonymous subtree. Therefore, it could insert element into <input>
element etc.
This patch adds new API to EditorDOMPointBase to compute ancestor point which
is not in native-anonymous subtree and make
HTMLEditor::GetBetterInsertionPointFor() use it to not return point in any
native-anonymous subtrees.
Like this adds new comments into the method, we should optimize the method
since it may create a lot of transactions and dispatch a lot of mutation
events.
MozReview-Commit-ID: FknJfu6QCjS
--HG--
extra : rebase_source : 39dc110b1101134f7c704e64dbff89171fe50e47
According to existing comments, TextEditor::TypedText() and
HTMLEditor::TypedText() are intentional bottleneck to debug. However, only
for that purpose, it and its internal methods are made virtual. This really
doesn't make sense.
So, this patch creates TextEditor::OnInputText() for callers of TypedText()
with non-empty string, TextEditor::OnInputParagraphSeparator() for callers
of TypedText() with eTypeBreak (Enter key or insertParagraphSeparator),
HTMLEditor::OnInputLineBreak() for callers of TypedText() with eTypeBR
(Shift + Enter or insertLineBreak). Additionally, this creates internal
non-virtual methods for XPCOM methods which are used as internal methods of
TypedText(). One is InsertTextAsAction() for nsIPlatintextEditor.insertText().
the other is InsertParagraphSeparator() for nsIPlaintextEditor.insertLineBreak().
Although those new methods are not have "WithTransaction" postfix, they must
be clearer they'll use transactions since user input and actions should be
undo-able.
MozReview-Commit-ID: AmOkMqovIKA
--HG--
extra : rebase_source : 9c0f4b25fa2a36ad2f3394f72eb290824c31d82a
TextEditor::CreateBR() is just a wrapper of TextEditor::CreateBRImpl() for
automatically retrieving Selection of the editor.
And TextEditor::CreateBRImpl() should be renamed to
TextEditor::InsertBrElementWithTransaction() for making it clearer what
it does.
MozReview-Commit-ID: D8sjVdLrVrd
--HG--
extra : rebase_source : f269f5c3ce598d221d7263c111475dab0dd5f19f
Similar to EditorBase::ReplaceContainerWithTransaction(),
EditorBase::InsertContainerAbove() may set an attribute to newly created element
if it's specified. However, for avoiding the null check, let's make them
as references rather than pointers and treat nsGkAtoms::_empty as nullptr for
making the code safer.
This patch removes "Above" from the method name since it's redundant.
"Insert" sounds like inserting a node, and "Container" means to keep existing
children with new element in EditorBase.
MozReview-Commit-ID: 6EnkKHynYSP
--HG--
extra : rebase_source : d4b4c1a611c46a0f4d86389aab3331af565199d2
This patch renames EditorBase::MoveNode() to
EditorBase::MoveNodeWithTransaction() and redesign its parameters including
replacing a set of container node and offset in it to EditorDOMPointBase.
However, it takes magic number -1 as meaning end of the container.
Therefore, this patch adds MoveNodeToEndWithTransaction() for keeping the
callers simple.
MozReview-Commit-ID: BeTq5c7GQNN
--HG--
extra : rebase_source : b3a617a5a1a493cb0fcbefe2d9a9708b0257b1a8