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
In the testcase, editing host is removed when first node removing, but
`HTMLEditor::Destroyed()` still returns `false`. So, ideally, we should add
a check of editing host validity in `Destroyed()`, but for now, we should make
the method check whether the handling range is still editable after running
each transaction.
Depends on D147723
Differential Revision: https://phabricator.services.mozilla.com/D147724
Currently, `TextEditor::OnFocus` does the things which were in
`EditorEventListener::OnFocus`, and they are not necessary at re-initializing
`Selection` in the anonymous subtree. Therefore, we should make it call
`EditorBase::OnFocus` directly.
Depends on D147623
Differential Revision: https://phabricator.services.mozilla.com/D147723
The reported testcase causes an incompatible behavior with the other browsers,
that is, `selectAll` command without focus in document whose body ends with
editable nodes selects the nodes in the selection root for the focused node (end
of the range in the normal direction). Therefore, `HTMLEditor` handles deletion
in odd state (without focus handling). So the root cause is a bug in selection,
but this bug as of the editor module should avoid the try of joining nodes which
are moved by a DOM mutation event listener at the initial deletion.
Differential Revision: https://phabricator.services.mozilla.com/D147623
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
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
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
`nsFocusManager` defines that focused content is at least `dom::Element`.
So `IMEStateManager` can handle focused content with `dom::Element` too.
Additionally, this patch makes `IMEStateManager` methods take references instead
of pointers as far as possible if they just return error for `nullptr`.
Differential Revision: https://phabricator.services.mozilla.com/D147133
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
It needs to work with the latest layout information to consider which cell
element is the insertion point due to rowspan and colspan. Therefore,
this patch makes it collects all cell data before touching the DOM except
the case that it needs to normalize the table to make it rectanble.
Note that the case requiring the normalizer should be fixed in a later patch.
This method is corresponding to an XPCOM method. Therefore, this is tested
by `test_nsITableEditor_insertTableColumn.html`.
And also it's used by the inline table editor, but we don't have automated tests
for this because of no API to get the buttons. Therefore, I tested it by my
hand.
Note that the old code fails to put caret to newly inserted cell at the reftest
situation. This fixes the bug too. Therefore, this changes the reftest's
reference.
Differential Revision: https://phabricator.services.mozilla.com/D146364
There is no direct test because of no corresponding XPCOM method, but this is
called only by `HTMLEditor::InsertTableColumnsWithTransaction()` which is
tested by `test_nsITableEditor_insertTableColumn.html`. Anyway, the chagne is
really simple.
Differential Revision: https://phabricator.services.mozilla.com/D146363
It refers the layout information for getting row/column index of selected cell
element or a cell element which contains selection. However, it can stop
referring it if all callers can specify insertion point of new cells, and it's
possible. Therefore, we can make it free from layout information.
Note that this blocks legacy mutation events during inserting table cell
elements, but perhaps this does not cause problems in the wild.
`DOMNodeInserted` will be fired after all cell elements are inserted, so
from point of view of the event listeners, editor content is different from
traditional behavior, but this works only when user uses inline table editor
which is disabled by default. I.e., in the wild, this path is rarely run.
Additionally, this patch makes it return `CreateElementResult` for the latter
changes which want to put caret to first inserted cell element.
Note that the changes are tested by `test_nsITableEditor_insertTableColumn.html`
and `test_nsITableEditor_insertTableCell.html`.
Differential Revision: https://phabricator.services.mozilla.com/D146361
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
It needs to work with the latest layout information to consider which cell
element is the insertion point due to rowspan and colspan. Therefore,
this patch makes it collects all cell data before touching the DOM except
the case that it needs to normalize the table to make it rectanble.
Note that the case requring the normalizer should be fixed in a later patch.
This method is corresponding to an XPCOM method. Therefore, this is tested
by `test_nsITableEditor_insertTableColumn.html`.
And also it's used by the inline table editor, but we don't have automated tests
for this because of no API to get the buttons. Therefore, I tested it by my
hand.
Depends on D146363
Differential Revision: https://phabricator.services.mozilla.com/D146364
There is no direct test because of no corresponding XPCOM method, but this is
called only by `HTMLEditor::InsertTableColumnsWithTransaction()` which is
tested by `test_nsITableEditor_insertTableColumn.html`. Anyway, the chagne is
really simple.
Depends on D146362
Differential Revision: https://phabricator.services.mozilla.com/D146363
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
It refers the layout information for getting row/column index of selected cell
element or a cell element which contains selection. However, it can stop
referring it if all callers can specify insertion point of new cells, and it's
possible. Therefore, we can make it free from layout information.
Note that this blocks legacy mutation events during inserting table cell
elements, but perhaps this does not cause problems in the wild.
`DOMNodeInserted` will be fired after all cell elements are inserted, so
from point of view of the event listeners, editor content is different from
traditional behavior, but this works only when user uses inline table editor
which is disabled by default. I.e., in the wild, this path is rarely run.
Note that the changes are tested by `test_nsITableEditor_insertTableColumn.html`
and `test_nsITableEditor_insertTableCell.html`.
Depends on D146360
Differential Revision: https://phabricator.services.mozilla.com/D146361
Masayuki Nakano
Emilio Cobos Álvarez
Molnar Sandor
Mark Banner
Kagami Sascha Rosylight
criss
Bogdan Szekely