Using the test for bug 1602526 as the basis for the new test but tweaking it by
adding the event listener used in the first testcase of the bug.

Original Revision: https://phabricator.services.mozilla.com/D184987

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

Bug 1840500 - Make `HTMLEditor::ClearStyleAt()` remove `<br>` for reuse before removing its parent from the tree. r=m_kato, a=RyanVM

Once a parent node is removed from the tree, the node may become not editable
because editable state "inherits" from ancestor nodes.
`HTMLEditor::ClearStyleAt` cleans up unnecessary parent inline elements first,
but if `<br>` element which should be reused in the block parent is contained
the inline elements, `HTMLEditUtils::IsRemovableNode()` will start returning
`false` for the `<br>` element because of in a document fragment which do not
contain an element whose `contenteditable` is `true`.  Then,
`MoveNodeWithTransaction` fails to move it because of unremovable.

Therefore, this patch makes the method move `<br>` element before removing
inline elements and use `InsertNodeWithTransaction` instead if `<br>` element
is an orphan node.

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

Bug 1852849 - Make `HTMLEditor::AutoInlineStyleSetter::ExtendOrShrinkRangeToApplyTheStyle` recompute common ancestor of the range if it updates the range r=m_kato a=RyanVM

In this case, `<font face="monospace">abc []<br></font>`, the range applying
new style will be extended as `<font face="monospace">abc [<br>}</font>` first.
https://searchfox.org/mozilla-central/rev/29bdf6ff9965a647c6f64d63fed2b5bd094532c7/editor/libeditor/HTMLStyleEditor.cpp#1944

Then, the start point should be shrunken and the range should become
`<font face="monospace">abc {<br>}</font>`.
https://searchfox.org/mozilla-central/rev/29bdf6ff9965a647c6f64d63fed2b5bd094532c7/editor/libeditor/HTMLStyleEditor.cpp#1977-1978

However, `commonAncestor` is still the text node because it's not updated
after extending the range to include the `<br>`.  Then,
`AutoInlineStyleSetter::GetNextEditableInlineContent` fails to get `<br>`
from the text node.
https://searchfox.org/mozilla-central/rev/29bdf6ff9965a647c6f64d63fed2b5bd094532c7/editor/libeditor/HTMLStyleEditor.cpp#1576-1578

Finally, the unexpected range computation will reach here with the text editor
and adjust the start of the range to start of the text node.
https://searchfox.org/mozilla-central/rev/29bdf6ff9965a647c6f64d63fed2b5bd094532c7/editor/libeditor/HTMLStyleEditor.cpp#420-423

Therefore, the new text which the new style should be applied is jumped to
start of the text node.

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

Bug 1840804 - Make `TextEditor::OnBlur` stop finalizing `Selection` if new element already gets focus r=m_kato, a=dsmith

Before bug 1770874, `EditorBase::OnBlur` checked that for both `TextEditor`
and `HTMLEditor`.  However, accidentally, I removed the check from `TextEditor`.
Therefore, a call of `EditorBase::FinalizeSelection()` will hide the caret
even after another editor gets focus.

Therefore, this patch just take it back into `TextEditor::OnBlur`.

Note that I don't think the design mode handling is required there because
`TextEditor`s shouldn't be created in the design mode document.

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

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

Bug 1835427 - Make `HTMLEditor::ClearStyleAt` track given point at calling `SplitAncestorStyledInlineElementsAt()` r=m_kato, a=dmeehan

It may be called with `AutoTransactionsConserveSelection` instance.
Therefore, it may return `aPoint` as-is even after modifying the DOM tree.
So it should track the point during a call of
`SplitAncestorStyledInlineElementsAt()`.

Depends on D179421

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

The `outdent` handler faces unexpected scenario due to the `<blockquote>`
element becomes not editable due to the `onstart` listener. The event listener
runs when the `<marquee>` moves from its container to new left node at splitting
it. Therefore, we need to put a lot of "removable node checks" before moving
nodes.

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

Bug 1828469, part 1: Prepare `RangeBoundaryBase`  to be able to handle non-`MutationObserver` Range classes. r=masayuki

In order to support `StaticRange`s, which are not `MutationObserver`s, RangeBoundaries need to have an alternative way of ensuring that `mRef` points to the correct node.
This is now done by validating `mRef` every time `Ref()` is called using the parent and offset.
For performance reasons, this is disabled by default and should only be used for `StaticRange`s.

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

I was going to write an automated test but turns out that some of this
became much harder to test after bug 582459 :-(

Let me know if you want me to take a look at writing a browser test
(since I think otherwise we can't test this, we need to move focus
outside of the active tab).

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

Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki

The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.

We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.

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

Backed out changeset e8b6a5dbf398 (bug 1817723) for causing mochitest failures in editor/libeditor/EditorEventListener.cpp CLOSED TREE

Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki

The EditorEventListener for HTMLEditor is registered on document,
which is problematic because it can't receive events when the focus is
switched between elements in the same shadow tree due to shadow dom
encapsulation.

We fix this by moving the EditorEventListener to nsWindowRoot so the
events can always be received.

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

Bug 1833320 - Make `HTMLEditor::HandleInsertParagraphInListItemElement` consider caret position without `WSScanResult` if it reaches a block boundary r=m_kato

When `WSRunScanner::ScanNextVisibleNodeOrBlockBoundary` reaches a block
boundary, it may return `WSScanResult` without valid position value from
this path:
https://searchfox.org/mozilla-central/rev/11a4d97a7b5cdfa133f4bda4525649f651703018/editor/libeditor/WSRunObject.cpp#1777-1782

That happens if the reason is `WSType::CurrentBlockBoundary` or
`WSType::OtherBlockBoundary` even in usual cases.

If it's `WSType::CurrentBlockBoundary`, `TextFragmentDataAtStartRef().EndRef()`
may point in a text node in the block, but its `GetEndReasonContent()` returns
the block.  I'm not sure whether this is intentional result. (I guess t's a
bug.)

If it's `WSType::OtherBlockBoundary`, `TextFragmentDataAtStartRef().EndRef()`
may point in the list item, but `GetEndReasonContent()` returns a child block.

Those scan result change needs to understand `TextFragmentData` behavior again,
but it's difficult as you know. Therefore, this fixes the caller side not to
use `WSScanResult::Point()` if it meets a block boundary since start of the
block boundary is a good place to put caret.

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

Bug 1826062 - Automatic fixes for upgrading Prettier to 2.8.8. r=mossop,perftest-reviewers,webcompat-reviewers,geckoview-reviewers,denschub,devtools-reviewers,sparky,calu

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

Bug 1826062 - Automatic fixes for Prettier 2.0.5 upgrade. r=mossop,perftest-reviewers,webcompat-reviewers,geckoview-reviewers,denschub,devtools-reviewers,sparky,owlish

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

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

Bug 1830419 - Convert PanelMutiView.jsm and CustomizableUITestUtils.jsm in browser/components/customizableui to ESMs r=search-reviewers,Standard8,devtools-reviewers

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

Bug 1832710 - Make `EditorBase::DispatchClipboardEventAndUpdateClipboard` handle `ePasteNoFormatting` event message r=m_kato

Just a mistake, it should treat `ePasteNoFormatting` as an equivalent of `ePaste`.

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

With the preceding patch, comment nodes are also moved at deleting a block/line
boundary.  However, this causes some WPT failures.  Therefore, this adds an
option to the related methods.

Note that Chrome removes all comment nodes in moving nodes.  However, I don't
have the motivation to do that because it requires additional cost and I have
no idea to improve the compatibility in usual web apps.  So I believe that
doing it wastes the runtime performance unless we'd get a bug reports by the
difference.

Therefore, this patch does not update WPTs too.

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

`HTMLEditUtils::CanNodeContain` does not handle comment nodes and cdata section
nodes (the latter one is available only in XHTML documents, it's treated as a
comment node in HTML documents).

When copying HTML from Word on Windows, that contains 2 comment nodes at
start of pasting body (which does not appear in clipboard viewer, so, Gecko
creates them somewhere) and that causes `HTMLEditUtils::CanNodeContain` returns
`false` for any parents.  Therefore,
`HTMLEditor::InsertNodeIntoProperAncestorWithTransaction` returns error
and the pasting fails with odd state and unexpectedly split the list item in
`HTMLWithContextInserter::InsertContents`.  Finally, undoing fails to do some
of them and causes destroying the editable nodes.

This patch makes `HTMLEditUtils::CanNodeContain` work with comment nodes
and cdata section nodes (the latter is treated as a comment node since there
is no "cdata" tag definition of `nsHTMLTag`) and
`HTMLEditor::InsertNodeIntoProperAncestorWithTransaction` just return
"not handled" result for some other types of nodes which cannot be inserted
in any elements.

Note that the result of pasting from Word is different from Chrome's result.
Chrome does not paste such comment nodes (but inserts comment nodes with
`insertHTML` command).  For now, I don't want to work on fixing this
compatibility issue since comment nodes does not cause any known troubles.
Therefore, this patch does not contain WPT updates.

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

Bug 1831434 - Make `EditorBase::InsertNodeWithTransaction` return error if inserted node is moved by JS r=m_kato

Some handlers, e.g., `HTMLWithContextInserter` may want to skip post processing
after inserting new node instead of immediately stop handling the action.
Currently, `HTMLWithContextInserter` correctly ignores the cases only when
`NS_ERROR_EDITOR_UNEXPECTED_DOM_TREE` is required.  Therefore, making
`InsertNodeWithTransaction` return the error makes `HTMLWithContextInserter`
work correctly in tricky cases.

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

Bug 1815969 - part 5: Make editors handle pasting something in new focused editor if a `paste` event listener moves focus r=m_kato

If a `paste` event listener moves focus, Chrome makes new editor keep handling
the pasting.  For the compatibility, we should follow it unless the new focused
element is in different document because user should allow to paste it
explicitly.

On the other hand, this just stops handling "cut" in same situation because
handling it requires to update clipboard without user's activation.  Therefore,
the clipboard content and/or the new editor content may be lost from the users
point of view.

Note that `nsContentUtils::GetActiveEditor` may return `HTMLEditor` instance
when focused element does not have `TextEditor` even when non-editable element
has focus.  Therefore, if it returns an `HTMLEditor`, we need to check whether
it's active in the DOM window with a call of `HTMEditor::IsActiveInDOMWindow`.

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

Bug 1815969 - part 4: Redesign `PasteTransferableAsAction` as same as the methods touched by the previous patch r=m_kato

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

Bug 1815969 - part 3: Redesign `EditorBase::PasteAsAction` and `EditorBase::PasteAsQuotationAsAction` r=m_kato

This patch makes `EditorBase` implement them as non-virtual methods and
implement their first part.  Then, they call new virtual methods to handle
paste and paste-as-quotation.

With this change, `TextEditor` starts to dispatch `paste` event when
paste-as-quotation.  The new test checks it.

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

Bug 1815969 - part 2: Make `PasteAsAction` and `PasteAsQuotationAsAction` stop taking `bool` argument r=m_kato

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

It does not handle critical cases properly, and it uses an out-param.
We can rewrite it with `Result`.  However, unfortunately,
`nsCopySupport::FireClipboardEvent` does not return error.  Therefore,
the root callers still need to treat the error cases as "canceled".

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

Backed out changeset 1a47a7baf147 (bug 1815969)
Backed out changeset 5cbc7a690417 (bug 1815969)
Backed out changeset d36c58bcd9d7 (bug 1815969)
Backed out changeset 644cbb12a064 (bug 1815969)
Backed out changeset a42837f38b02 (bug 1815969)

Bug 1815969 - part 5: Make editors handle pasting something in new focused editor if a `paste` event listener moves focus r=m_kato

If a `paste` event listener moves focus, Chrome makes new editor keep handling
the pasting.  For the compatibility, we should follow it unless the new focused
element is in different document because user should allow to paste it
explicitly.

On the other hand, this just stops handling "cut" in same situation because
handling it requires to update clipboard without user's activation.  Therefore,
the clipboard content and/or the new editor content may be lost from the users
point of view.

Note that `nsContentUtils::GetActiveEditor` may return `HTMLEditor` instance
when focused element does not have `TextEditor` even when non-editable element
has focus.  Therefore, if it returns an `HTMLEditor`, we need to check whether
it's active in the DOM window with a call of `HTMEditor::IsActiveInDOMWindow`.

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

Bug 1815969 - part 4: Redesign `PasteTransferableAsAction` as same as the methods touched by the previous patch r=m_kato

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

Bug 1815969 - part 3: Redesign `EditorBase::PasteAsAction` and `EditorBase::PasteAsQuotationAsAction` r=m_kato

This patch makes `EditorBase` implement them as non-virtual methods and
implement their first part.  Then, they call new virtual methods to handle
paste and paste-as-quotation.

With this change, `TextEditor` starts to dispatch `paste` event when
paste-as-quotation.  The new test checks it.

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

Bug 1815969 - part 2: Make `PasteAsAction` and `PasteAsQuotationAsAction` stop taking `bool` argument r=m_kato

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

It does not handle critical cases properly, and it uses an out-param.
We can rewrite it with `Result`.  However, unfortunately,
`nsCopySupport::FireClipboardEvent` does not return error.  Therefore,
the root callers still need to treat the error cases as "canceled".

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

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

This test checks the behavior for Thunderbird.  Therefore, we don't need to
check it in different origin's `<iframe>`.

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

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

Bug 1807495 - part 1: Make `Document` notify `HTMLEditor` and `IMEStateManager` of pseudo focus change when editing state of focused editing host or document is changed r=smaug,m_kato

`IMEStateManager` basically runs at focus change.  However, when `designMode`
is set to `"off"` or focused editing host becomes non-editable (removing
`contenteditable` attribute or `contenteditable` attribute is set to `false`),
IME may be disabled without a focus change.  Therefore, `Document` needs to
notify `IMEStateManager` of the timing.

Additionally, `nsFocusManager` does not change focus when focused element
becomes not focusable (bug 1807597).  Therefore, `Document` needs to kick
`focus` or `blur` event handler of `HTMLEditor` when active editing host
becomes not editable.

However, if an ancestor of focused element becomes editable, I think that
`HTMLEditor` does not work well without focus move because it computes
editing host with current editing state in a lot of places, but `Selection`
and `nsFocusManager::GetFocusedElement` keeps working with previous focused
element which is now a editable child of editing host.  Therefore, this patch
marks them as `todo` in the new tests.

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

Make all UA widgets also NAC.

Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.

This is important because two callers depend on this difference:

 * The style system, since we still want to match content rules from
   stylesheets in the UA widget. We also match user rules, which is a
   bit sketchy, but that was the previous behavior, will file a
   follow-up for that.

 * The reflector code, since we want the scope for UA widgets to not
   include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
   got it wrong.

After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.

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

Although we have removed Spatial navigation by bug 1341737, we still touch
`snav.enabled`. Let's remove it.

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

This API is temporarily available and useful for web app developers who want to
stop supporting Gecko specific join/split direction handling as soon as possible
and who do not want Mozilla block their release schedule by rescheduling of
shipping the new behavior.  Additionally, adding this command allows web apps
detects whether Gecko supports the new behavior and whether it's enabled.

On the other hand, We don't want to ship opt-out API because it's hard to keep
maintaining the legacy behavior specific paths.  Therefore, the command does
nothing if web app calls
`Document.execCommand("enableCompatibleJoinSplitDirection", false "false")` if
the new behavior is enabled by default.

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