This patch makes it take `AutoRangeArray` and it can save a snapshot of the
ranges and restore it like `AutoSelectionRestorer`.
For accessing `HTMLEditor::RangeUpdaterRef` for clearing the saved ranges,
`AutoRangeArray` needs to store `HTMLEditor`. Therefore, its constructors
and the destructor cannot be inlined in the header due to the include-hell.
Differential Revision: https://phabricator.services.mozilla.com/D149089
It's always work with `Selection` ranges. Then, it should be treated within
`AutoRangeArray` which can be initialized with `Selection` ranges automatically.
Then, we can making `HTMLEditor` simpler.
Note tha this tries to make it get editing host when the corresponding
public method is called (after dispatched `beforeinput` event if handling a
users' operation). However, as commented in
`HTMLEditor::SetParagraphFormatAsAction`, it breaks a tricky crash test.
Therefore, only the format block path computes it after the preparation.
Differential Revision: https://phabricator.services.mozilla.com/D149079
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Its callers check `EditorBase::Destroyed()` with at least adding 4 lines, and
some callers do not check this important state. So, we should make it check
`Destroyed()` at last and omit the additional error check in the caller sites.
Note that it's a virtual method, but `HTMLEditor` checks whether it's a
removable node or not. So, we should can merge it into `EditorBase`. This
patch does it too.
Differential Revision: https://phabricator.services.mozilla.com/D148084
It's currently computes the corresponding editing host from the focus node of
`Selection` with climbing up the DOM tree. So, it does not just return a stored
element. Therefore, some callers use it multiple times. For avoiding it, we
should rename it to explain that it computes the editing host.
Note that I think that we should make it takes a node to compute editing host
without `Selection` for solving the case of no selection ranges. Therefore,
I don't like to include more information into the name.
Differential Revision: https://phabricator.services.mozilla.com/D147504
It returns the anonymous `<div>` element if the instance is a `TextEditor`, and
compute editing host otherwise. So it's unclear what it returns. Additionally,
all users except `EditorBase::CreateTransactionForCollapsedRange` are the
methods of `HTMLEditor`. Therefore, we should remove it and unwrap the code
which it's done.
Differential Revision: https://phabricator.services.mozilla.com/D147503
I'd like to split it for `TextEditor` and `HTMLEditor`. `HTMLEditor` does not
require flushing the layout because it's required by `TextEditor` if and only if
a preceding `focus` event listener or the `Element.focus` caller reframes
`<input>` or `<textarea>` element (bug 1755104). So this would fix bug 1760045.
Differential Revision: https://phabricator.services.mozilla.com/D147143
Creating both `DeleteNodeTransaction` and `InsertNodeTransaction` wastes
memory. They should be done in an instance instead.
Fortunately, no edit action listener checks whether the deleted node is still
in the composed document or not, etc. Therefore, we can simply notify them of
both deletion and insertion which were done in
`EditorBase::InsertNodeWithTransaction` and
`EditorBase::DeleteNodeWithTransaction`. Note that previously, the range
updater needs to ignore the notifications from them while the node is being
moved. However, it does not require anymore. Therefore, this patch makes it
stop locking, and that would fix minor problem in the case of legacy mutation
event listeners run another edit action.
On the other hand, this changes some edge cases handling of
`MoveNodeWithTransaction` which are detected by the WPT. According to the
previous result of applying this patch, `nsINode::InsertBefore` fails and that
leads some errors at updating the changed range. I guess that the cause is
that there is some bugs at updating insertion point after deleting the node from
the DOM tree around here:
https://searchfox.org/mozilla-central/rev/0ffae75b690219858e5a45a39f8759a8aee7b9a2/editor/libeditor/HTMLEditor.cpp#5058-5071
However, it's safely fixed by the new code which does not remove the node from
the DOM tree explicitly. So, I think that it's safe to accept this behavior
change for web apps in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D146397
This patch also makes it inserts table rows immediately after the previous
row element of the found reference row element to make it insert new table
rows immediately after there when inserting position is "after". Typically,
it's the parent `<tr>` element of `aCellElement`. Therefore, this approach
can preserve text nodes immediately after it which was intentionally inserted
by the web apps.
Differential Revision: https://phabricator.services.mozilla.com/D146365
Our table editor depends on layout information for getting raw/column position
of a cell, checking rawspan/colspan information and table size. Therefore,
they require the latest information, but they don't flush pending layout by
themselves. Therefore, this patch makes them do it by themselves and deleting
unnecessary hack from their tests.
Differential Revision: https://phabricator.services.mozilla.com/D146359
This change is tested by `test_nsITableEditor_getFirstRow.html` and
`test_nsITableEditor_insertTableColumn.html`.
Depends on D146361
Differential Revision: https://phabricator.services.mozilla.com/D146362
Our table editor depends on layout information for getting raw/column position
of a cell, checking rawspan/colspan information and table size. Therefore,
they require the latest information, but they don't flush pending layout by
themselves. Therefore, this patch makes them do it by themselves and deleting
unnecessary hack from their tests.
Differential Revision: https://phabricator.services.mozilla.com/D146359
This patch makes `TransactionManager` store `HTMLEditor`, and `HTMLEditor`
send notifications from `TransactionManager` to `ComposerCommandsUpdater`.
Depends on D145663
Differential Revision: https://phabricator.services.mozilla.com/D145664
The creation and initialization cost of `nsRange` is expensive. And just
comparing DOM points does not require the checks of ancestors which are
required by `nsRange` to observe DOM mutations. Therefore, although the
logic is not exactly same, we can skip the additional unnecessary cost.
Note that the Editor module checks without `nsRange`'s strict initialization
in most places so that it must not be required to do the strict check only in
`SelectionState`.
Additionally, this moves some definitions of `SelectionState` methods to
its header for making them inlined since the dependency is now reduced.
Finally, some methods are renamed to align to `Selection` API.
Depends on D145226
Differential Revision: https://phabricator.services.mozilla.com/D145227
This patch also makes that `HTMLWithContextInserter::InsertContents`
collect moving children first. Then, move each one with a transaction.
This is standard manner in these days to avoid infinite loop caused by
moving the removed child back by a mutation event listener.
Differential Revision: https://phabricator.services.mozilla.com/D144658
It's called only by `HTMLEditor::HandleInsertParagraphInListItemElement` and
it also just returns a point to put caret computed from the result of
`CopyLastEditableChildStylesWithTransaction` and its caller changes the
selection. Therefore, it's enough to make it return a recommend point to
put caret.
Differential Revision: https://phabricator.services.mozilla.com/D144654
Now, it does not require to update selection, and its result may have a point
to put caret it is used to doing. This patch makes it stop collapsing selection
after each split, and instead, makes all callers of it collapse selection if
it's (probably) necessary.
Note that the method may not split any nodes but return it as "handled".
Therefore, the callers do not check whether a splitting node occurred **but**
suggesting point to put caret is invalid or the other cases. Therefore, in
strictly speaking, this patch changes the existing behavior, but it should not
affects web apps in the wild because of the low usage of the legacy mutation
event listeners.
Differential Revision: https://phabricator.services.mozilla.com/D144650
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
Unfortunately, we need to keep `InsertNodeTransaction::RedoTransaction()`
touching `Selection` for now because redoing `Selection` management is out
of scope of this bug (it's probably require big changes, but no benefits for
now).
Differential Revision: https://phabricator.services.mozilla.com/D144645
In theory, methods which touch the DOM tree should take `EditorDOMPoint` rather
than `EditorRawDOMPoint`. And now, we can return meaningful value if it
succeeded, with `Result`.
Therefore, this patch makes it return `Result<EditorDOMPoint, nsresult>` instead
of taking an out argument, and take only `EditorDOMPoint` rather than taking any
type of `EditorDOMPointBase` since it's always converted to `EditorDOMPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D143881
The implicit copy constructors and `operator=` makes it harder to realize
that implicit conversion wastes the runtime cost. Therefore, this patch
replaces them with a template method to convert the `EditorDOMPointBase` type.
Differential Revision: https://phabricator.services.mozilla.com/D143878
Headers in editor module has a lot of forward declarations for avoiding the
include hell and has a lot of helper template classes.
Forward declarations of template classes is really messy and I'd want to
avoid the duplication because it blocks changing template class. Therefore,
centralizing forward declarations makes the headers cleaner and maintaining
template classes easier. Therefore, this patch adds a new header file which
has only forward declarations and some aliases.
It'd be better to define `enum class`es in it like `EventForwards.h` for
reducing the dependencies between headers, but currently this does not do it
for making the new file simpler as far as possible.
Removing `EditActionListener.h` is because it's unused.
Removing `AutoTopLevelEditSubActionNotifier` is because it's renamed to
`AutoEditSubActionNotifier`.
https://hg.mozilla.org/mozilla-central/rev/6de55c5b5f8d5f92389d0d244d2bced1f979ade9
Differential Revision: https://phabricator.services.mozilla.com/D143817
Now, `EditorBase::CollapseSelectionTo*()` set the interline position if it's
explicitly set to the `EditorDOMPointBase` parameter. Therefore, editor should
use the feature as far as possible instead of calling
`Selection::SetInterlinePosition` directly.
Differential Revision: https://phabricator.services.mozilla.com/D143816
Some of them were `HTMLEditor` so that we need to fix it to `EditorBase`, and
also this patch fixes `NS_ERROR_EDITOR_DESTROYED` handling around them.
Differential Revision: https://phabricator.services.mozilla.com/D143815
First, move methods of `HTMLEditor` which collapse `Selection` to `EditorBase`.
Then, make editor stop accessing `Selection::CollapseInLimiter` directly.
Differential Revision: https://phabricator.services.mozilla.com/D143814
