Bug 1779846 - Remove an unneeded if-statement in TextServicesDocument::OffsetEntryArray::FindWordRange(). r=masayuki, a=dmeehan

This patch fixed a regression caused by Bug 1730084 Part 4
https://phabricator.services.mozilla.com/D125434, which is intended to preserve
the behavior of `WordBreaker::FindWord()`.

Before Bug 1730084 Part 4, `WordBreaker::FindWord()` returns
`[aTextLen + 1, aTextLen + 1]` only when `aOffset > aTextLen`.
But `WordBreaker::FindWord()` had an assertion `aOffset <= aTextLen`
to guarantee the caller never passes `aOffset > aTextLen`. Thus, we can never
go into the `if (res.mBegin > strLen)` in
`TextServicesDocument::OffsetEntryArray::FindWordRange()`.

However, Bug 1730084 Part 4 wrongly changes the if-statement to
`if (range.mEnd == range.mBegin)`, and makes it reachable when
`TextServicesDocument::OffsetEntryArray::FindWordRange()` passes
`aPos == aLen` into `WordBreaker::FindWord()`. This makes `InitSpellChecker()`
failed when `enableSelectionChecking=true`.

This patch deletes the originally unreachable error handling if-statement, and
adds an assertion to guarantee `strOffset` and `strLen` is valid.

Differential Revision: https://phabricator.services.mozilla.com/D156210

Bug 1785801 - Make `RangeUpdater::SelAdjJoinNodes` take the ex-offset of right node. r=m_kato, a=RyanVM

In bug 1739524, I misunderstood the meaning of `aOffset` of `SelAdjJoinNodes`.

After joining 2 nodes, and a point points right node which will have ex-left
node content, the point needs to point ex-start of the right node to keep
next insertion point as-is.  Therefore, it's not useful with new join nodes
direction, it needs to know the ex-offset of the right node.

This is a backport patch of https://phabricator.services.mozilla.com/D155438 for
ESR 102.

Differential Revision: https://phabricator.services.mozilla.com/D156271

Bug 1773848 - Make the for-loop in the lambda in `HTMLEditor::InsertTableRowsWithTransaction` refer only `cellDataInLastRow` r=m_kato a=RyanVM

It's renamed from `CellData`, but `cellData` still exists in the wider scope.
https://searchfox.org/mozilla-central/rev/f6a2ef2f028b8f1eb82fa5dc5cb1e39a3baa8feb/editor/libeditor/HTMLTableEditor.cpp#923-924

Therefore, these lines are wrong:
https://searchfox.org/mozilla-central/rev/f6a2ef2f028b8f1eb82fa5dc5cb1e39a3baa8feb/editor/libeditor/HTMLTableEditor.cpp#1049,1053

because `cellData` was in the for-loop:
https://searchfox.org/mozilla-central/rev/bc4493c72442ad55aecf6b575edb0df4ed18b113/editor/libeditor/HTMLTableEditor.cpp#1008-1009,1020,1022,1026

Differential Revision: https://phabricator.services.mozilla.com/D152144

Differential Revision: https://phabricator.services.mozilla.com/D151682

Bug 1761160: Disable spellechecking in the textarea for the blur-focus test. r=masayuki, a=test-only

Differential Revision: https://phabricator.services.mozilla.com/D150281

Differential Revision: https://phabricator.services.mozilla.com/D150156

This adds a check to see if the encoded word is not empty and does not start
with the null character. Hunspell accepts C-style strings and marks the empty
string as correctly spelled. This prevents other dictionaries from detecting
misspelled strings in languages that use a different charset, which has lead
to problems when using the en-US dictionary packaged with Firefox and Greek,
Hebrew and Russian dictionaries, where misspellings are not detected in the
non-English language.

Differential Revision: https://phabricator.services.mozilla.com/D149899

Backed out 5 changesets (bug 1770133) on beta, large refactoring during soft code freeze, needs nightly bake time a=backout

Backed out changeset 8596922e3e2e (bug 1770133)
Backed out changeset 6151c1cf0404 (bug 1770133)
Backed out changeset 7322de6f865f (bug 1770133)
Backed out changeset df84cc3d5d23 (bug 1770133)
Backed out changeset b92de4a984f1 (bug 1770133)

Backed out 8 changesets (bug 1770874) on beta, large refactoring during soft code freeze, needs nightly bake time a=backout

Backed out changeset 5d866154c49f (bug 1770874)
Backed out changeset 75a25dbc4c88 (bug 1770874)
Backed out changeset 049366a15c3c (bug 1770874)
Backed out changeset 9bb0023ac750 (bug 1770874)
Backed out changeset 526ea470c4dd (bug 1770874)
Backed out changeset b635369043bd (bug 1770874)
Backed out changeset 77b1aeae51f1 (bug 1770874)
Backed out changeset 6946652d4ed9 (bug 1770874)

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

Similar to the previous patch, we should split the method into `TextEditor`
and `HTMLEditor`.

Differential Revision: https://phabricator.services.mozilla.com/D147144

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

Note that `EditorBase::OnBlur` will be simpler at the last patch.

Differential Revision: https://phabricator.services.mozilla.com/D147142

Differential Revision: https://phabricator.services.mozilla.com/D147141

Bug 1770874 - part 4: Move most part of `EditorEventListener::Focus` into `EditorBase::OnFocus` r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D147140

This method also can be protected in a following patch.

Differential Revision: https://phabricator.services.mozilla.com/D147139

It's currently a public method, but it can be protected in a following patch.

Differential Revision: https://phabricator.services.mozilla.com/D147138

Differential Revision: https://phabricator.services.mozilla.com/D147137

Bug 1770133 - part 3: Make `EditorBase::GetFocusedContent()` return `Element*` instead of `nsIContent*` r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D147134

`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

Differential Revision: https://phabricator.services.mozilla.com/D147369

Bug 1770684 - Mark `IMEStateManager::SetIMEState` and its callers in `IMEStateManager` as `MOZ_CAN_RUN_SCRIPT` r=smaug

Differential Revision: https://phabricator.services.mozilla.com/D147071

Bug 1680611 - part 6: Mark `nsFocusManager::MoveCaretToFocus()` and its callers in `nsFocusManager` as `MOZ_CAN_RUN_SCRIPT` r=smaug

Differential Revision: https://phabricator.services.mozilla.com/D147065

Backed out 4 changesets (bug 1770727) for causing mochitest failures in test_bug1180105/test_access_control. CLOSED TREE

Backed out changeset 6323b526b0ac (bug 1770727)
Backed out changeset fc7ea80aa2ff (bug 1770727)
Backed out changeset 2a358ba86652 (bug 1770727)
Backed out changeset 464d1af6523b (bug 1770727)

Bug 1770727 - Fix failures of ESLint rule mozilla/use-includes-instead-of-indexOf in sjs files. r=Gijs

Depends on D147081

Differential Revision: https://phabricator.services.mozilla.com/D147082

Bug 1766355 - part 9: Make `HTMLEditor::ReplaceContainerWithTransactionInternal` and its callers use `MoveNodeTransaction` and return `CreateElementResult` r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146405

Bug 1766355 - part 8: Make `HTMLEditor::RemoveBlockContainerWithTransaction` stop touching `Selection` directly r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146404

Bug 1766355 - part 7: Rewrite `HTMLEditor::RemoveContainerWithTransaction` with `MoveNodeTransaction` and make it stop touching `Selection` directly r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146403

Bug 1766355 - part 6: Make `HTMLEditor::MoveOneHardLineContents` return `MoveNodeResult` with caret point suggestion r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146402

Bug 1766355 - part 5: Make `HTMLEditor::MoveChildrenWithTransaction` and `HTMLEditor::MoveNodeOrChildrenWithTransaction` stop touching `Selection` directly r=m_kato

Unfortunately, they call each other.  Therefore, this patch updates these 2
methods once.

Differential Revision: https://phabricator.services.mozilla.com/D146401

Bug 1766355 - part 4: Make `HTMLEditor::MoveNodeWithTransaction` and `HTMLEditor::MoveNodeToEndWithTransaction` return `MoveNodeResult` r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146400

Differential Revision: https://phabricator.services.mozilla.com/D146399

Differential Revision: https://phabricator.services.mozilla.com/D146398

Bug 1766355 - part 1: Add `MoveNodeTransaction` to handle delete node and insert node in a transaction class instance r=m_kato

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

Bug 1730442 - part 7: Rewrite `HTMLEditor::InsertTableRowsWithTransaction()` to collect any cell information before touching the DOM tree r=m_kato

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

Bug 1730442 - part 6: Make `HTMLEditor::InsertTableColumnsWithTransaction()` collect all necessary data before touching the DOM tree r=m_kato

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

Bug 1730442 - part 5: Rewrite `HTMLEditor::GetNextTableRowElement()` as returning `Result<RefPtr<Element>, nsresult>` r=m_kato

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

Bug 1730442 - part 4: Rewrite `HTMLEditor::GetFirstTableRowElement()` as returing `Result<RefPtr<Element>, nsresult>` r=m_kato

This change is tested by `test_nsITableEditor_getFirstRow.html` and
`test_nsITableEditor_insertTableColumn.html`.

Differential Revision: https://phabricator.services.mozilla.com/D146362

Bug 1730442 - part 3: Make `HTMLEditor::InsertTableCellsWithTransaction()` work without layout information r=m_kato

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

Bug 1730442 - part 2: Rewrite `HTMLEditor::GetSelectedOrParentTableElement()` as returing `Result<RefPtr<Element>, nsresult>` r=m_kato

Differential Revision: https://phabricator.services.mozilla.com/D146360