At initializing new element which has not been connected, undo transactions
are not necessary because just removing the new element gets same result for
users. Therefore, they should be able to work without transactions.
Differential Revision: https://phabricator.services.mozilla.com/D140468
For making initializing new element safer and faster, it's better to initialize
new element's attributes and appending children before inserting the new element
into the DOM tree.
Differential Revision: https://phabricator.services.mozilla.com/D140465
When `Selection` instance is updated, the old selection may be in batch.
In the case, `UpdateSelectionCache` should clean up the batch in the old
selection and start new one in the new selection instead.
Differential Revision: https://phabricator.services.mozilla.com/D139349
Similar to the previous patch, in the splitting a node case,
`SplitNodeWithTransaction` notifies `RangeUpdater`. Currently, this must not
cause any trouble, but for consistency with `DoJoinNodes`, `DoSplitNode` does
it instead.
Different from the previous patch, `SelAdjSplitNode` is not called if splitting
the node fails. Therefore, it's enough to do it at end of `DoSplitNode`.
Differential Revision: https://phabricator.services.mozilla.com/D140464
Currently, it's notified by `JoinNodesTransaction::DoTransactionInternal` so
that it's `SplitNodeTransaction::UndoTransaction` cannot track the DOM point
and this might cause odd editing result if `execCommand("undo")` is called
while `HTMLEditor` handles an edit action.
For avoiding to duplicate the code, it should be handled in
`HTMLEditor::DoJoinNodes`.
Differential Revision: https://phabricator.services.mozilla.com/D140463
First, it should not store split point with `EditorDOMPoint` because it has
child node pointer and other flags but they are never used and they make
the footprint worse. Therefore, this patch makes it exactly same structure
as `JoinNodesTransaction`.
Additionally, this patch removes "left" and "right" words especially from
the member names and variable names (preparation of bug 1735608).
Differential Revision: https://phabricator.services.mozilla.com/D140461
Similar to the previous patch, in the splitting a node case,
`SplitNodeWithTransaction` notifies `RangeUpdater`. Currently, this must not
cause any trouble, but for consistency with `DoJoinNodes`, `DoSplitNode` does
it instead.
Different from the previous patch, `SelAdjSplitNode` is not called if splitting
the node fails. Therefore, it's enough to do it at end of `DoSplitNode`.
Depends on D140463
Differential Revision: https://phabricator.services.mozilla.com/D140464
Currently, it's notified by `JoinNodesTransaction::DoTransactionInternal` so
that it's `SplitNodeTransaction::UndoTransaction` cannot track the DOM point
and this might cause odd editing result if `execCommand("undo")` is called
while `HTMLEditor` handles an edit action.
For avoiding to duplicate the code, it should be handled in
`HTMLEditor::DoJoinNodes`.
Depends on D140462
Differential Revision: https://phabricator.services.mozilla.com/D140463
First, it should not store split point with `EditorDOMPoint` because it has
child node pointer and other flags but they are never used and they make
the footprint worse. Therefore, this patch makes it exactly same structure
as `JoinNodesTransaction`.
Additionally, this patch removes "left" and "right" words especially from
the member names and variable names (preparation of bug 1735608).
Differential Revision: https://phabricator.services.mozilla.com/D140461
This patch just cleans up the method code for making the changes for bug 1735608
simpler. This does not change any behavior.
Depends on D140010
Differential Revision: https://phabricator.services.mozilla.com/D140011
This patch just cleans up the method code for making the changes for bug 1735608
simpler. This does not change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D140010
It's already disabled since 96 and now is late 97 cycle in the release channel,
but I've not gotten regression reports about this. Therefore, we should get
rid of it from the tree completely, then, we can make
`HTMLEditor::CreateAndInsertElementWithTransaction` greater for its callers.
Depends on D139717
Differential Revision: https://phabricator.services.mozilla.com/D139718
This push some post processing of joining nodes into `JoinNodesTransaction` and
`HTMLEditor::DidJoinNodes()` to make `HTMLEditor::JoinNodesTransaction()`
simpler and the new method does not use the "left"/"right" words at post
processing.
This changes the logic a bit so that it may change some behavior if web apps
uses some legacy mutation events, but it must be rare case because the other
browsers don't fire them synchronously.
Depends on D139716
Differential Revision: https://phabricator.services.mozilla.com/D139717
This patch renames members and variables in it not to use "left" and "right"
words to preparing to support both direction joining. So this patch does not
change any behavior.
Depends on D139715
Differential Revision: https://phabricator.services.mozilla.com/D139716
For consistency with the other things in editor module, it should be "nodes"
rather than "node" since 2 nodes are joined by it.
Differential Revision: https://phabricator.services.mozilla.com/D139715
When the `focus` event listener of editors which is in the system group runs,
a preceding `focus` event listener may have already blurred the focused element,
but it may have not been applied to the DOM tree yet. In this case, checking
whether the editor still has focus or has already blurred without flushing the
pending things does not make sense. Therefore, this patch makes the `Focus`
do it first.
Note that this patch adds 3 crash tests, but only the `<textarea>` case crashes
without this patch. The others are only for detecting new regressions.
Differential Revision: https://phabricator.services.mozilla.com/D139089
It's not split to each chunk with IIFE nor the message explain what is the
expected result. This just rewrites it without changing what's are tested
except adding a call of `testFocusMove` with `<button>` in the main editor
(i.e., editable button).
Depends on D138876
Differential Revision: https://phabricator.services.mozilla.com/D138877
Querying selection for getting writing mode may run script in the main process
if focus is in it. For avoiding new users of writing mode at selection **only**
when the value is required during an editable content has focus,
`TextEventDispatcher` should always store writing mode at receiving focus
notification.
Differential Revision: https://phabricator.services.mozilla.com/D138008
I'd like to use it in `IMEData.h`. However, adding new include into it may
cause bustage with MinGW, and it's included by `nsIWidget.h` because `nsIWidget`
requires some classes defined in `IMEData.h`. Therefore, I'd like to make a
new header file for avoiding the include hell.
Differential Revision: https://phabricator.services.mozilla.com/D138007
The method caches a DOM point, but it is not tracked correctly.
This patch adds some validations into it and one of its callee,
`HTMLEditor::MoveOneHardLineContents`. Additionally, making
`EditorDOMPointBase::Offset` avoid accessing `Maybe`'s storage when it's
`Nothing` in release builds as the last resort.
Differential Revision: https://phabricator.services.mozilla.com/D136994
Due to a Selection API's bug, `Selection::Modify` may move selection into
native anonymous subtree. Although it should be fixed in the side, but
`HTMLEditor` should make range boundaries climb up to outside native anonymous
subtrees.
Depends on D137526
Differential Revision: https://phabricator.services.mozilla.com/D137527
Those methods use `RangeBoundary` or `RangeBoundaryBase`, and it makes reading
the code harder because of poor API comparing from `EditorDOMPointBase`, and
anyway they are converted to `EditorDOMPointBase`.
Therefore, they should take `EditorDOMPointBase` or `EditorDOMRangeBase`
instead.
Differential Revision: https://phabricator.services.mozilla.com/D137526
`MOZ_KNOWN_LIVE RefPtr<Foo> mFoo` is not treated as safe because its raw pointer
is referred with operators but they are not checked at handling `MOZ_KNOWN_LIVE`
annotation.
Additionally, when members marked as `MOZ_KNOWN_LIVE` are in the stack, they
are also not treated as safe, but they should be safe in most cases.
With these changes, `HTMLTableEditor.cpp` can get rid of a lot of
`MOZ_KnownLive` method calls.
Differential Revision: https://phabricator.services.mozilla.com/D136122
With the change of the previous patch, `HTMLEditor` won't delete empty elements
in the inserted HTML content. However, at bug 1123505, it intentionally tried
to delete empty list elements which have no list item elements since such
list elements won't be editable. Therefore, the following patch makes some
tests in `test_copypaste.html` fail.
https://searchfox.org/mozilla-central/rev/3de56eb5f266f523340e739ae1b53258e0a95dfe/dom/base/test/copypaste.js#343,360
Unfortunately, the broken behavior is compatible with Chrome (Chrome accept
list elements which have no list item elements), but it does not make sense for
Gecko's builtin editor. Therefore, I think that we should keep our traditional
behavior with deny-list.
This patch makes `FragmentFromPasteCreator` delete list elements which have no
list item elements and are empty from the inserting document fragment.
Differential Revision: https://phabricator.services.mozilla.com/D136211
This is same issue as bug 1747008, but the remover is different method, that is
`HTMLEditor::RemoveEmptyNodesIn` called by
`HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal`. It should be called
only when the flag which was added by bug 1747008 is **not** set to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D136210
This is a simple mistake. When it should refer inserting a list item element
result, it refers inserting a list element result instead.
Differential Revision: https://phabricator.services.mozilla.com/D137393
`HTMLEditor` assumes that inline elements cannot have block elements. However,
it's not so if it's created by DOM APIs like `Node.appendChild` or making a
custom element an editing host.
Therefore, it's not unexpected case that only start or end of a range does not
have a block ancestor element. So this patch makes `AutoBlockElementsJoiner`
not stop handling the deletion in the case.
Differential Revision: https://phabricator.services.mozilla.com/D136698
Ideally, it should not be called when the editor cannot insert new text node.
However, the callers are complicated. Therefore, let's check in it for avoiding
making the callers more complicated. Fortunately, this is not realistic path
for normal web apps. Therefore, the compatibility of the behavior is not
matter. That's the reason why this patch does not have a test comparing the
result.
Differential Revision: https://phabricator.services.mozilla.com/D135826
`IsSetAndValid` method of `RangeBoundaryBase` and `EditorDOMPointBase` should
return `false` if points a removed node. However, while a node is being
removed, the node still keeps referring the parent, but it has already removed
from the child node chain of the parent. In this moment, returning `true` may
not be expected by the callers because the point becomes invalid soon with
the parent being cleared.
Differential Revision: https://phabricator.services.mozilla.com/D135190
Starting from bug 1730429, we strip empty inline elements at caret for
compatibility with Blink/WebKit. However, we should not do it for the elements
which are intentionally inserted (from `inserthtml` command, paste and DnD).
All the cases are handled by `HTMLEditor::HTMLWithContextInserter` so that
it should prevent the new clean up with `TopLevelEditSubActionData`.
Note that `inserthtml` command handling of Blink is really odd. It inserts
the empty inline elements of the adding testcases into different place so that
Chrome does not pass the new tests. However, it does not make sense and I
believe that it's out of scope of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D135195
It calls `nsINode::GetNextNode()` to scan first descendant list item in the
list without specifying the root node to scan within. Therefore, it may return
following list item element of the given list element if the list element does
not have children.
Differential Revision: https://phabricator.services.mozilla.com/D135110
This is a follow up fix for the previous patch. Even if `IsSelectionEditable()`
is not used before starting to handle an edit action, it should be aborted by
failing to get editing host.
Depends on D134658
Differential Revision: https://phabricator.services.mozilla.com/D134659
Perhaps due to a bug Selection and/or Range API, selection may be in a native
anonymous subtree, and if the content is editable like in anonymous `<div>`
element in `<input>` or `<textarea>`, `HTMLEditor` may put unexpected element
into the anonymous `<div>` element.
For avoiding it, `EditorBase::IsSelectionEditable()` should return `false`
when it detects this odd situation. Then, editing commands do not work in
the anonymous subtree.
Differential Revision: https://phabricator.services.mozilla.com/D134658
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
Offset in a node is declared as "unsigned long" by the standards and we don't
limit node can have less than `INT32_MAX`. So it should return `uint32_t`, but
it also needs to represent the case of "not found". For consistency with some
other APIs like `nsContentUtils::ComparePoints`, using `Maybe` must be a good
style rather than `Result<uint32_t, bool>`.
This patch fixes the callers in assertions for example.
Differential Revision: https://phabricator.services.mozilla.com/D131335
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
It has two methods which take (signed) `long` argument to specify offset in a
DOM node, but it's declared as "unsigned long" in the standards. And now,
they work with rewritten Selection API which take `uint32_t` so that they should
use `unsigned long` for making the handling simpler and safer.
Differential Revision: https://phabricator.services.mozilla.com/D131034
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Our internal code can touch internal `Selection` object of `<input>` and
`<textarea>`, thus, selection ranges in them may be not in the text node.
Therefore, we should make `TextEditor` instance try to shrink the deleting
ranges into the text node first.
In a followup bug (perhaps, bug 1734846), we should split the deletion code into
`TextEditor` and `HTMLEditor` for making the code simpler and never regressed.
Differential Revision: https://phabricator.services.mozilla.com/D133181
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Similarly, `SplitNodeTransaction::RedoTransaction()` has its own code, but it
does not work well. Let's make it use `HTMLEditor::DoSplitNode()` instead.
This fixes bug 1740656.
Differential Revision: https://phabricator.services.mozilla.com/D132123
`JoinNodeTransaction::UndoTransaction()` has its own splitting code. However,
it has some bugs, it does not handle surrogate pairs correctly and it does not
care selections. `HTMLEditor::DoSplitNode()` is used for splitting a DOM node
from `SplitNodeTransaction::DoTransaction()`. So that we should make
`JoinNodeTransaction::UndoTransaction()` should use `HTMLEditor::DoSplitNode()`
for saving the maintenance cost.
Differential Revision: https://phabricator.services.mozilla.com/D132122
This patch implements `JoinNodesResult` class which callers of
`JoinNodesWithTransaction()` can access removed node, existing (joined) node and
joined point with logical named accessors, and makes
`JoinNodesWithTransaction()` return it.
Then, the callers don't need to change at fixing bug 1735608.
Differential Revision: https://phabricator.services.mozilla.com/D132120
`CreateElementTransaction` is too similar to `InsertNodeTransaction`. Only the
difference is, CreateElementTransaction::DoTransaction() creates an element via
editor instance and marks it dirty before inserting the new element. E.g.,
selection management and whether inserting new node or not at "redo" are same.
So, for the maintenance cost reason, we should get rid of
`CreateElementTransaction`, but for now, we should just make `HTMLEditor` use
`InsertNodeTransaction` instead, with a new pref to make it possible to back it
out the new behavior even after shipping.
Differential Revision: https://phabricator.services.mozilla.com/D132119
This is a different point from `InsertNodeTransaction`. If reference node has
been removed from the DOM tree, it tries to insert the given node to end of
the container instead of returning error. This is an edge case of "redo", and
this is tested by WPT. If we'd need to back it out with Normandy after shipping
this changes, we'd need to uplift WPT expectation change. However, we should
avoid this situation. Therefore, this patch fixes the bug of
`CreateElementTransaction` first.
Differential Revision: https://phabricator.services.mozilla.com/D132118
With this patch, callers of it can handle left and right node logically instead
of assuming that one is split and the other is new one.
Depends on D131748
Differential Revision: https://phabricator.services.mozilla.com/D131749
First, left/right node accessors are not used so that we can get rid of them.
However, we should have similar methods which can retrieve original node and
new node. Therefore, this adds `GetNewContent()` and `GetOriginalContent()`.
Next, `SplitPoint()` should return both `EditorDOMPoint` and `EditorRawDOMPoint`
for avoiding unnecessary conversion from `EditorRawDOMPoint` to
`EditorDOMPoint`. Therefore, this patch makes it a template method too.
Finally, this patch adds helper methods to get point of each related content.
E.g., `AtNewContent()` corresponding to `GetNewContent()`.
Differential Revision: https://phabricator.services.mozilla.com/D131748
With this patch, we stop registering `Alt+A` as a shortcut key for "Select All" on Linux and register `Ctrl+A` instead, which is the default shortcut for the command on other GTK applications, Chromium, and Windows. `Alt+A` was also causing a bug for menubar navigation because it hijacks `Alt+A` access key. This patch does not stop Linux environments from registering `Alt+A` as a shortcut key for "Select All"; it just drops Gecko's additional, non-standard shortcut key definition, and defaults to `Ctrl+A` instead.
Differential Revision: https://phabricator.services.mozilla.com/D131062
There are a lot of places which calls
`HTMLEditor::MaybeSplitAncestorsForInsertWithTransaction()` and then calls
`HTMLEditor::CreateAndInsertElementWithTransaction()` with split point of the
preceding result. It's better to wrap them in a method for reducing the
maintenance cost.
`HTMLEditor::CreateOrChangeBlockContainerElement()` handles to calling them
safer than the others so that let's use this code for the new method. The
additional change won't change the most web apps which don't touch the DOM
tree from legacy mutation event listeners.
Depends on D131198
Differential Revision: https://phabricator.services.mozilla.com/D131199
I realized that it's now used only by `HTMLEditor` so that we can move it
into `HTMLEditor` and we can make `CreateElementTransaction` treat `HTMLEditor`
directly rather than via `EditorBase`.
Differential Revision: https://phabricator.services.mozilla.com/D131198
It touches the DOM tree only with `SplitNodeTransaction()` and it now returns
`NS_ERROR_EDITOR_DESTROYED` so that the callers don't need to check whether
the editor is destroyed or alive by themselves.
Depends on D131043
Differential Revision: https://phabricator.services.mozilla.com/D131044
For making the code simpler, this patch makes it returns
`Result<nsCOMPtr<nsIContent>, nsresult>` instead of using `ErrorResult`.
This must make the construction faster and callers simpler.
Depends on D130950
Differential Revision: https://phabricator.services.mozilla.com/D131043
It does the following things when caret is collapsed in a text node in a `<p>`
or `<div>` element.
1. Split the text node containing caret to insert `<br>` element
2. Insert `<br>` element after it
3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>`
4. Delete the `<br>` element if unnecessary from the left paragraph
#3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls
`WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before
splitting the block. However, in the case (caret is at middle of a text node),
the text has already been split to 2 nodes because of #1. Therefore, it fails
to handle to keep the white-space visibility.
So that I believe that the root cause of this bug is, the method does much
complicated things which are required, and doing the redundant things will
eat memory space due to undo transactions. However, for now, I'd like to fix
this with a simple patch which just call the preparation method before splitting
the text node because I'd like to uplift this if it'd be approved (Note that
this is not a recent regression, the root cause was created by bug 92686 which
was fixed in 17 years ago:
<https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>,
but must be annoying bug for users who see this frequently).
The new WPTs are pass in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D130950
Similar to the previous patch, this patch also make it track invisible
white-space ranges and clear outdated things.
And this makes it cache some information instead of tracking some changes
because of performance reason.
Depends on D131037
Differential Revision: https://phabricator.services.mozilla.com/D131038
It `pointToSplit` should be tracked at replacing text, but I have no idea how
to test this because it replaces the text after the split point.
Differential Revision: https://phabricator.services.mozilla.com/D131036
Currently, it assumes that new node is the left node and split node is the
right node. However, we need to make it possible to handle the case that
right node is new one for fixing bug 1735608.
Depends on D130458
Differential Revision: https://phabricator.services.mozilla.com/D130624
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
There is 2 overloads. One is `TextServicesDocument`'s method, and the latter is
for `nsIEditActionListener`. The latter could occur if `TextServicesDocument`
is added to the editor when there is no inline spellchecker, `EditorSpellCheck`
or `mozSpellChecker`.
https://searchfox.org/mozilla-central/rev/d2f8488b6a704443a5c5bfc6d2878171b5f0d393/editor/libeditor/EditorBase.cpp#2388,2391,2393,2396,2398
I don't know whether this is possible case, but unfortunately,
`nsIEditActionListener::DidJoinNodes()` is not implemented by JS and implemented
only by `TextServicesDocument`. Therefore, we can make it "noscript" and use
non-scriptable classes as arguments.
This patch makes them get jointed point and removed content node and the joining
direction for fixing bug 1735608. Unfortunately, there is no test framework
to check the result in `TextServicesDocument` nor the new path. The latter
should be tested when we fix bug 1735608 later.
Differential Revision: https://phabricator.services.mozilla.com/D130458
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
Currently, it assumes that `aLeftNode` is new node and the other is the original
one. However, we need the opposite case when we fix bug 1735608.
Unfortunately, we cannot test the new path until we fix bug 1735608. Therefore,
the new path may contain some bugs.
Differential Revision: https://phabricator.services.mozilla.com/D130427
Currently, it assumes that all children or text data of `aRightContent` is
moved into `aLeftContent`. However, we need the opposite case when we fix
bug 1735608.
Unfortunately, we cannot test the new path until we fix bug 1735608. Therefore,
the new path may contain some bugs.
Differential Revision: https://phabricator.services.mozilla.com/D130426
The telemetry result is written in bug 1706266 comment 1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706266#c1
`increasefontsize`, `decreasefontsize`, `gethtml`, `heading` and `readonly` are
obviously not used by web apps in the wild. Therefore, they can be disabled
in all channels.
`contentReadOnly` and `insertBrOnReturn` are odd. The usage is really low (less
than 1% of beta users). However, the number of documents which used the command
is about 1k samples. The result of the commands are not tiny (making the editor
not editable or changing the behavior at typing `Enter` key in `<div>`, `<p>`,
etc). Therefore, it's hard to use them in web apps which supports not only
Gecko. So I guess that they are collected the number of used by automated
tests of somebody because of the constant number in other beta versions.
Perhaps, we should disable it only in Nightly channel for now, and after a
couple of releases, we should try to disable those commands too later.
Depends on D130328
Differential Revision: https://phabricator.services.mozilla.com/D130329
I'd like to split utilities for all editors and only for `HTMLEditor`.
This moves some trivial classes into new `HTMLEditHelpers.h`. Perhaps, it's
better if we can move them into `HTMLEditUtils.h`, but it has too many inline
method definitions so that adding new classes into it makes it much bigger.
Depends on D130349
Differential Revision: https://phabricator.services.mozilla.com/D130425
Now, it does not notify nobody before joining the nodes. Therefore, it can
return error immediately if it fails to create a transaction to join the given
nodes.
Additionally, this patch makes it return `NS_ERROR_EDITOR_DESTROYED` if the
editor is destroyed while it handles to join nodes. Therefore, we can get rid
of the check by the callers.
Differential Revision: https://phabricator.services.mozilla.com/D130349
`TopLevelEditSubActionData::WillJoinNodes()` and
`TopLevelEditSubActionData::DidJoinNodes()` are called only by
`HTMLEditor::JoinNodesWithTransaction()`. `WillJoinNodes()` assumes that
all children or text data in `aLeftContent` is moved to head of `aRightContent`.
Therefore, it just stores length of `aLeftContent` and `DidJoinNodes()` lets
`AddPointToChangedRange()` know the joined point.
Same value is stored by `HTMLEditor::JoinNodesWithTransaction()`. Therefore,
it can create same DOM point at calling `DidJoinNodes()` so that we can get
rid of `WillJoinNodes()`.
Differential Revision: https://phabricator.services.mozilla.com/D130348
Masayuki Nakano
Iulian Moraru
Norisz Fay
Mirko Brodesser
Emilio Cobos Álvarez
Joel Maher
Tom Schuster
Chris Peterson
Richard Marti
Dan Minor
Sandor Molnar
Greg Tatum
Ting-Yu Lin
ssummar
Cristian Tuns