Including it in `HTMLEditor.h` causes creating static constructors for
the modules which include `HTMLEditor.h`. And the public methods are used
only in the `libeditor`. Therefore, we can make `HTMLEditor.h` stop including
it and stop exposing `JoinSplitNodeDirection.h`.
Differential Revision: https://phabricator.services.mozilla.com/D159363
They are used in public inline methods of `HTMLEditor`. Therefore, they should
be defined in an exposed header file without other internal use things for the
editor module. Then, we can stop exposing `HTMLEditHelpers.h`.
Depends on D158632
Differential Revision: https://phabricator.services.mozilla.com/D158633
The reason why the changes of `SplitNodeTransaction` is smaller than
`JoinNodesTransaction` is, `HTMLEditor::DoSplitNode` does almost all things
instead.
Differential Revision: https://phabricator.services.mozilla.com/D158102
This patch adds new path to adjust selection for the new split node direction.
So this does not change any behavior of the existing path.
Differential Revision: https://phabricator.services.mozilla.com/D158100
This patch add new path to adjust selection for the new join nodes direction.
So this does not change any behavior of the existing path.
Differential Revision: https://phabricator.services.mozilla.com/D158098
Currently I'm think that the split/join node direction should be managed per
`HTMLEditor` instance because per transaction makes undo/redo handling
complicated and may require additional space to save it in each transaction
instance. However, the direction should be changeable with new Gecko specific
`execCommand` to support both direction until creating first split/join node
transaction or anytime with clearing the transactions.
Differential Revision: https://phabricator.services.mozilla.com/D149192
This patch allows methods which split some nodes to return new candidate
caret position and makes callers of them consider whether applying it to
the selection immediately or not.
Differential Revision: https://phabricator.services.mozilla.com/D144648
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
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
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
Masayuki Nakano