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

# ignore-this-changeset

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

Bug 1893119: Part 10 - Move MaybeEditorDeletedSourceNode from nsIDragService to nsIDragSession  a=diannaS

MaybeEditorDeletedSourceNode was defined on nsIDragService but is more appropriately defined on nsIDragSession.  This was not an issue previously since those were the same object.

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

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

Since we now add the widget to the event in
dispatchDOMEventViaPresShellForTesting, WidgetGUIEvents that are sent in
mochitests via that method need to transform their screen coordinates by
nsIWidget::WidgetToScreenOffset, to mirror the transformation by
BrowserParent::TransformParentToChild that they don't get because they
skip the parent process.

This exposes a bunch of things that were done to work around this bug.  They
are cleaned up here.

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

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

Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.

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

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

Bug 1906727 - Make `HTMLEditor::SplitAncestorStyledInlineElementsAt` check attr value type first r=peterv, a=dmeehan

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

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

clang 19 will start complaining about it. See
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#96

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

Bug 1898408 - Make our editor disconnect `<br>` element temporarily when its type is changed from or to padding one r=m_kato

Currently, the `<br>` element type -- whether normal `<br>` element or padding
`<br>` element for empty editor or last line -- is managed by the flags of
`nsINode`.  Therefore, changing the flag does not cause mutation, so
`IMEContentObserver` cannot observe the type changes.  However,
`ContentEventHandler` treats the padding `<br>` elements as invisible.
Therefore, when a `<br>` element becomes a padding one, `IMEContentObserver`
needs to notify IME of atext removed notification, and also when a `<br>`
element becomes a normal one (i.e., visible), `IMEContentObserver` needs to
notify IME of a text added notification.

Therefore, this patch makes `EditorBase` disconnect the `<br>` element
temporarily to make `IMEContentObserver` observable the type change.

Depends on D211698

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

Bug 1893351 - part 2: Make `HTMLEditor::HandleInsertText` stop inserting text into existing text nodes if it's a middle line of inserting text r=m_kato

When 2nd or later line, the method inserts one-line text to start of a `Text`
node following `<br>` which is inserted by the method.  Then, splits the `Text`
node to insert another `<br>`.  This creates a lot of unnecessary
`SplitNodeTransaction`s and that causes a lot of copying memory operation to
set the data of the right `Text` node.

This patch makes the method creates a `Text` node when inserting a middle line
of inserting text.  Therefore, `SplitNodeTransaction` is created at most one
(to split a `Text` node if the caller wants to insert a text middle of it).

Depends on D211697

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

Bug 1893351 - part 1: Add an option to make `EditorBase::InsertTextWithTransaction` always create a `Text` node r=m_kato

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

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

Bug 1877513 - Make `HTMLEditor` deletes only preceding lines of right child block if the range starts from start of a line r=m_kato

Currently, the editor of Gecko always unwraps first line of the right child
block after deleting selected range when the range starts in a parent block
and ends in a child block.  This behavior is almost same as the other browsers,
but the other browsers deletes only preceding lines of the right child block
(i.e., without unwrapping the first line of the right child block) if the range
starts from start of a preceding line, for example, when deleting
`<div>abc<br>[def<p>g]hi<br>jkl`, Gecko moves "hi" to the parent `<div>`,
but the other browsers keeps it in the child `<p>`.

For emulating this special handling, we need to touch 2 paths.

One is `Backspace` when selection is collapsed at start of the child block.  In
this case, only when the preceding line is empty, i.e., there are 2 line breaks
(either `<br>` or `\n` in `white-space: pre-*`), the following break should
be deleted, but the child block should not be touched.

The other is, deleting when selection is not collapsed or `Delete` when
selection is collapsed at immediately before the child block.  In the latter
case, `HTMLEditor::HandleDeleteSelection` extends `Selection` using
`nsFrameSelection`.  Then, handle it with same path as deleting non-collapsed
range.

The former is handled with `HandleDeleteLineBreak` and
`ComputeRangeToDeleteLineBreak`.  The latter is handled with
`HandleDeleteNonCollapsedRange` and `ComputeRangeToDeleteNonCollapsedRange`.
The new handlers use the `ComputeRangeToDelete*`.  Therefore, `beforeinput`
reports exactly same range from `getTargetRanges`.  However, existing paths
do not use same approach and this patch makes `HandleDeleteNonCollapsedRange`
fall it back to `HandleDeleteNonCollapsedRange`.  Therefore, some `if` checks
in `HandleDeleteNonCollapsedRange` are ugly, but I have no better idea to
implement this smarter.

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

Backed out changeset 67a63b95c31e (bug 1877513) for causing build bustages on HTMLEditorDeleteHandler.cpp CLOSED TREE

Bug 1877513 - Make `HTMLEditor` deletes only preceding lines of right child block if the range starts from start of a line r=m_kato

Currently, the editor of Gecko always unwraps first line of the right child
block after deleting selected range when the range starts in a parent block
and ends in a child block.  This behavior is almost same as the other browsers,
but the other browsers deletes only preceding lines of the right child block
(i.e., without unwrapping the first line of the right child block) if the range
starts from start of a preceding line, for example, when deleting
`<div>abc<br>[def<p>g]hi<br>jkl`, Gecko moves "hi" to the parent `<div>`,
but the other browsers keeps it in the child `<p>`.

For emulating this special handling, we need to touch 2 paths.

One is `Backspace` when selection is collapsed at start of the child block.  In
this case, only when the preceding line is empty, i.e., there are 2 line breaks
(either `<br>` or `\n` in `white-space: pre-*`), the following break should
be deleted, but the child block should not be touched.

The other is, deleting when selection is not collapsed or `Delete` when
selection is collapsed at immediately before the child block.  In the latter
case, `HTMLEditor::HandleDeleteSelection` extends `Selection` using
`nsFrameSelection`.  Then, handle it with same path as deleting non-collapsed
range.

The former is handled with `HandleDeleteLineBreak` and
`ComputeRangeToDeleteLineBreak`.  The latter is handled with
`HandleDeleteNonCollapsedRange` and `ComputeRangeToDeleteNonCollapsedRange`.
The new handlers use the `ComputeRangeToDelete*`.  Therefore, `beforeinput`
reports exactly same range from `getTargetRanges`.  However, existing paths
do not use same approach and this patch makes `HandleDeleteNonCollapsedRange`
fall it back to `HandleDeleteNonCollapsedRange`.  Therefore, some `if` checks
in `HandleDeleteNonCollapsedRange` are ugly, but I have no better idea to
implement this smarter.

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

`nsDOMAttributeMap::GetAttribute` creates `dom::Attr` so that it's not cheap.
Instead it should access `Element::mAttrs` with the accessors or
`BorrowedAttrInfo`.

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

Bug 1891659 - Make `AutoBlockElementsJoiner::DeleteTextAtStartAndEndOfRange()` handle the case when the range in a text node r=m_kato

It assumes that the range is always starts and ends in different node.  This
is true for now, but this will be called with a text node to delete only
preformatted line break.  Note that the only caller of it does not need the
text node(s) if it becomes empty.  Therefore, this patch makes it remove the
text node in such case.

Note that the test changed in
`input-events-get-target-ranges-deleting-in-list-items.tentative.html` was
wrong and only Firefox passed it because the range description was
`(#text "", 0) - (#text "", 10)` since the text nodes are removed after
deleting the text data of them.  Now, they become
`(#text "list-item1", 0) - (#text "list-item2", 10)`.

Depends on D207688

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

Bug 1891656 - Make `HTMLEditUtils::GetMostDistantAncestorEditableEmptyInlineElement()` use `Element::FromNode()` r=m_kato

It uses `AsElement()` which always casts itself to `Element*`, however, the
instance may be non-element node if there is no empty parent of `aEmptyContent`.

Fortunately, all callers of this method uses the result as `nsIContent*` to
call `DeleteNodeWithTransaction()`.  Therefore, we don't have crash bugs caused
by this.

Depends on D207687

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

Bug 1891408 - part 3: Make some callers of `WSScanResult::Point_Deprecated()` use new methods r=m_kato

`Point_Deprecated()` is really error-prone since its result meaning is different
whether the scan direction is backward or forward.  Therefore, if a caller wants
a point in a text node and the direction is only one of them, we can change it
to use `WSScanResult::PointAtReachedContent()` or
`WSScanResult::PointAfterReachedContent()`.

Depends on D207686

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

When it's called, it just returns at the reached content node.  However, this
does not make sense when it reached a character in the text node.

Depends on D207685

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

They point the found character point if scanning forward.  However, they point
the next character point if scanning backward.  Therefore, I don't have any
good idea to name them.  Therefore, I rename them to `*_Deprecated()` and the
callers should use better name method later.

Depends on D207684

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

When `WSScanResult::ReachedCurrentBlockBoundary()` returns `true`, it may have
reached inline editing host rather than editable block.  Therefore, the
method name is definitely error-prone.  This patch adds new state and all
users of `WSType::CurrentBlockBoundary` keeps checking the new type too for
keeping current behavior.

I think that we should make `WSRunScanner` aware of inline editing host next
to block boundary before removing odd check of
`ReachedInlineEditingHostBoundary()`, `StartsFromInlineEditingHostBoundary()`
and `EndsByInlineEditingHostBoundary()` to avoid unexpected regressions in the
wild.

Depends on D207683

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

Bug 1885822 - part 3: Make `WSScanResult` always have editable element with `mContent` if it reached current block boundary r=m_kato

Different from the comment around setter of `WSType::CurrentBlockBoundary`,
neither `HTMLEditUtils::GetNextLeafContentOrNextBlockElement` nor
`HTMLEditUtils::GetPreviousLeafContentOrPreviousBlockElement` returns
`nullptr` when it reaches non-editable element, and the setters always set
`mContent` to `aEditableBlockParentOrTopmostEditableInlineElement`.  Therefore,
`mContent` is always an editable element when `ReachedCurrentBlockBoundary()`
returns `true`.

Depends on D207682

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

Bug 1885822 - part 2: Make `WSScanResult` always have non-null `mContent` if it reached something r=m_kato

Currently, it checks whether `mContent` is `nullptr` or not even if the scanner
reached something.  However, this makes the users of this object check whether
it has reasonable content or not and that makes the users messy.  Therefore,
the scanning method should guarantee that it's always error if it does not reach
any content.

Depends on D207681

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

Bug 1885822 - part 1: Make `WSScanResult` created with `WSType::InUncomposedDoc` if the scan is tried in uncomposed tree r=m_kato

This case should never happen because nobody can check proper editable state
in uncomposed tree unless the uncomposed tree has its own editing host.
Therefore, this patch adds assertions into the scanning methods too.

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

Bug 1890915 - Make `EditorBase::CloneAttributesWithTransaction()` collect all attributes before updating the DOM tree r=m_kato

`while (RefPtr<Attr> attr = attributes->Item(0))` causes a warning in
`nsDOMAttributeMap::IndexedGetter()` because of out of bounds.  Additionally,
we should not make a loop with live DOM tree information if the loop updates
the DOM tree.  Therefore, this patch makes it collect all attributes first
before touching the DOM tree.

Depends on D207240

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

Bug 1890912 - Fix warning spam in `HTMLEditor::SplitAncestorStyledInlineElementsAtRangeEdges()` r=m_kato

The cause is an expected case.  Therefore, using `NS_WARN_IF` is wrong.

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

Bug 903746 - part 2: Add `textInput` event and make `EditorBase` dispatch it as a default action of `beforeinput` r=smaug

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

Backed out 2 changesets (bug 903746) for causing non-unified build bustages on nsIPrincipal.h. CLOSED TREE

Backed out changeset c80afc8b7c2a (bug 903746)
Backed out changeset 0ac710612d09 (bug 903746)

Bug 903746 - part 2: Add `textInput` event and make `EditorBase` dispatch it as a default action of `beforeinput` r=smaug

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

Bug 1887719 - More consistently use UTF8String/nsCString for URLs. r=necko-reviewers,webidl,anti-tracking-reviewers,places-reviewers,jari,kershaw,janv,smaug,hsivonen

Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...

This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.

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

Bug 1705440 - remove old modal prompt implementation, r=mconley,webdriver-reviewers,extension-reviewers,desktop-theme-reviewers,tabbrowser-reviewers,whimboo,rpl

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

Backed out 2 changesets (bug 1883557, bug 1705440) for causing failures at browser_ext_sidebarAction_contextMenu.js. CLOSED TREE

Backed out changeset 89f62e190e69 (bug 1705440)
Backed out changeset 79dfddac72f9 (bug 1883557)

Bug 1705440 - remove old modal prompt implementation, r=mconley,webdriver-reviewers,extension-reviewers,desktop-theme-reviewers,tabbrowser-reviewers,whimboo,rpl

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

Bug 1883562 - part 2: Make `EditorBase::DeleteRangesWithTransaction` and the fallback path of `AutoDeleteRangesHandler` work with single range r=m_kato

Although from the maintenance cost point of view, we should not duplicate
`EditorBase::DeleteRangesWithTransaction`, but let's add a wrapper for it
for making the callers simpler.

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

It and its helper class, `AutoInclusiveAncestorBlockElementsJoiner` work with
multiple ranges, but they handle special cases only with the first range.
That means that deleting content will be different if same structure is selected
with multiple ranges and that must be not expected by the users.

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

The purpose of this patch is to prevent users to make changes to
read-only editors.

This patch forces `IsCommandEnabled()` to return false for read-only
editors for "standard" editor commands that could have an associated
icon or menu entry and are therefore user-accessible.

This patch does not modify/test any paste commands or any of the
advanced internal editor commands.

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

Backed out changeset dd6b961d3b69 (bug 1883367) for causing mochitest failures in test_command_state_when_readonly_in_chrome.html CLOSED TREE

The purpose of this patch is to prevent users to make changes to
read-only editors.

This patch forces `IsCommandEnabled()` to return false for read-only
editors for "standard" editor commands that could have an associated
icon or menu entry and are therefore user-accessible.

Advanced internal editor commands are not touched.

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