When using autocorrect, we should use `insertReplacementText` according
to https://github.com/w3c/input-events/issues/152. So I would like to
add eContentCommandReplaceText command for this.
Also, this command has an option that is source string text. When
processing text subsitution, parent process doesn't know whether
target replaced text is modified. So I add this option for check.
Differential Revision: https://phabricator.services.mozilla.com/D213511
It means that "treat non-editable things as visible" when it's not set.
However, it's odd. You must assume that if no option is set, `IsEmpty()` etc
should treat non-editable nodes as visible things. Therefore, this renames it
to `TreatNonEditableContentAsVisible` and changing all callers of
`HTMLEditUtils::IsEmptyNode`, `HTMLEditUtils::IsEmptyInlineContainer`,
`HTMLEditUtils::IsEmptyBlockElement` and
`HTMLEditUtils::CollectEmptyInlineContainerDescendants`. So, this does not
change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D196813
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
Similar to the previous patch, this changes a lot of lines. However, I think
that it's not so hard to investigate regression point in this patch because
`CreateNodeResultBase` is not used so many times at handling on edit action.
Differential Revision: https://phabricator.services.mozilla.com/D157575
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
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
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
For avoiding updating `CellData` member(s) to make the static analysis work,
`CellData::Update` shouldn't be used. Instead, it should be created for each
cell whose detail is required.
Differential Revision: https://phabricator.services.mozilla.com/D146137
The callers don't need the detail of the error, and the runtime cost of
`ErrorResult` may not be cheap because it sometimes appear in profiles.
Therefore, they should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D146136
They will be changed to factory methods. Therefore, they shouldn't be in
middle of the cpp file.
This patch just moves them without any changes.
Differential Revision: https://phabricator.services.mozilla.com/D146135
For avoiding updating `CellData` member(s) to make the static analysis work,
`CellData::Update` shouldn't be used. Instead, it should be created for each
cell whose detail is required.
Differential Revision: https://phabricator.services.mozilla.com/D146137
The callers don't need the detail of the error, and the runtime cost of
`ErrorResult` may not be cheap because it sometimes appear in profiles.
Therefore, they should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D146136
They will be changed to factory methods. Therefore, they shouldn't be in
middle of the cpp file.
This patch just moves them without any changes.
Differential Revision: https://phabricator.services.mozilla.com/D146135
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
`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
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
Building with `ac_add_options --disable-unified-build` on macOS hits the following -Wunreachable-code-return warnings-as-errors:
editor/libeditor/HTMLEditor.cpp:4341:26 [-Wunreachable-code-return] 'return' will never be executed
editor/libeditor/HTMLTableEditor.cpp:1629:10: warning: 'return' will never be executed [-Wunreachable-code-return]
Differential Revision: https://phabricator.services.mozilla.com/D126441
It's hard to understand each caller of `HTMLEditor::IsEmptyNode()` tries to
check with multiple `bool` arguments. Therefore, they should be replaced
with an `EnumSet`.
Note that only the first argument is reverted the meaning. Therefore, if
it's omitted or `false`, `EmptyCheckOption::TreatSingleBRElementAsVisible`
is specified explicitly. Otherwise, i.e., `true`, nothing should be
specified.
Differential Revision: https://phabricator.services.mozilla.com/D112513
The lifetime of it is guaranteed by `AutoEditActionDataSetter` which grabs
`Selection` until it's destroyed, and it's a stack only class and created
at first step of all public method calls. Therefore, we can mark it as
`MOZ_KNOWN_LIVE` and we can change it returning reference of `Selection`
instead of reference of `RefPtr<Selection>`.
Differential Revision: https://phabricator.services.mozilla.com/D110896
The method is tested by `test_nsITableEditor_getFirstSelectedCellInTable.html`.
And now, nobody uses `CellAndIndexes` so that this patch removes it.
Depends on D94239
Differential Revision: https://phabricator.services.mozilla.com/D94240
Unfortunately, there is no automated tests for `nsITableEditor.joinTableCells()`
and it'll take a couple of days to write its testcase because of too big
method. And it's not so important for Firefox (although it's used in
comm-central). Therefore, this patch skips to check it.
Note that `CellAndIndexes` uses `HTMLEditor::GetFirstSelectedTableCellElement()`
to retrieve first selected cell element and then, it retrieves its indexes.
https://searchfox.org/mozilla-central/rev/61728de8273c04fe2417c475fc0637e8b79210d7/editor/libeditor/HTMLTableEditor.cpp#4090,4098,4109
Therefore, this patch makes it stop using this simple structure too.
Depends on D94235
Differential Revision: https://phabricator.services.mozilla.com/D94236
Makoto Kato