This is a bug of the assertion.
When there is 2 text nodes are adjacent, one ends with a visible character and
the other starts with a white-space, and the deleting range ends at end of the
first one, `GetReplaceRangeDataAtEndOfDeletionRange()` returns a range starting
with the start of the second one since it does not need to touch the first one.
Therefore, the white-space range start may be after the deleting range end.
This patch adds new condition to the `MOZ_ASSERT_IF`, and test this specific
case with new `MOZ_ASSERT_IF`.
Differential Revision: https://phabricator.services.mozilla.com/D110068
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This test case doesn't generate body element and isn't general case. Actually
since we don't manage current IME focus on IMEStateManager, we shouldn't notify
IMEContext of widget.
Differential Revision: https://phabricator.services.mozilla.com/D108366
When typing at edge of a link, editor splits the link element at the edge (i.e.,
creating an empty link element). Then, unlink the new link element (i.e.,
clearing the "link style"). At this time, `class` attribute and `style`
attribute are cloned to new `<span>` element for keeping the original style.
However, in this case, other browsers discard the specified style of the link.
On the other hand, when unlinking a link with `execCommand("unlink")`, the
other browsers keep specified style coming from `style` attribute.
Therefore, this patch adds new state to `PropItem`, which indicates whether
the `class` and `style` attribute should be cloned or discarded. And then,
when preparing for inserting text, this patch makes it pass to the utility
method.
For better compatibility, we should stop cloning `class` attribute, but not
in this bug because this patch should be minimized for requesting uplift to
beta channel.
Differential Revision: https://phabricator.services.mozilla.com/D107801
E.g., comment node is an invisible data node, and it's not handled by
`HTMLEditor` nor `ContentEventHandler`. Therefore, `IMEContentObserver`
should ignore invisible data nodes, which are not derived from `dom::Text`.
Differential Revision: https://phabricator.services.mozilla.com/D107590
For making delete handlers simpler, and set better target ranges to the
corresponding `beforeinput` event, we should ignore non-editable ranges
before handling deletion.
This patch makes editor stop handling deleteion when a range crosses editing
host boundaries. In this case, Gecko has done nothing, but fired
`beforeinput` event. Note that Blink deletes editable contents in the range
**until** it meets first non-editable content, but I don't think this is
a good behavior because it makes things complicated. Therefore, I filed
a spec issue: https://github.com/w3c/editing/issues/283
On the other hand, this behavior change causes different behavior in
https://searchfox.org/mozilla-central/source/editor/libeditor/crashtests/1345015.html
It tries to insert paragraph into `<html>` element, but our editor currently
does not support it. Therefore, it hits `MOZ_ASSERT`. Therefore, this patch
added a new check into `HTMLEditor::InsertParagraphSeparatorAsSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D107588
Blink treats each non-editable node as an atomic object. E.g., deleting or
forward-deleting from next to a non-editable element, it deletes only one
non-editable element.
Unfortunately, our layout treat adjacent non-editable nodes as a node.
Therefore, the adding WPTs do not work, but they are not new regression of
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D107587
It does not make sense `WSRunScanner` handles invisible white-spaces in
non-editable elements. Therefore, this patch makes it stop handling in the
cases.
Note that this change causes new fail of some WPTs. That will be fixed by
the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D107586
No behavior change. We were already returning false for HTML editor +
non-editable so we can simplify it a bit.
Depends on D107511
Differential Revision: https://phabricator.services.mozilla.com/D107512
There are 2 bugs. One is that `SplitNodeDeepWithTransaction` tries to split
comment node, but it fails. The other is, the failure result is not checked
by `HandleInsertParagraphInHeadingElement`. Therefore, the original head
element's previous node may not be a heading element.
Depends on D106591
Differential Revision: https://phabricator.services.mozilla.com/D106620
browserscope is no longer maintained, so contenteditable=false case is
incorrect now. So I would like to update this tests for non editable case.
Differential Revision: https://phabricator.services.mozilla.com/D96299
Since `WSScanResult` can return non-editable/non-removable text node,
`HandleDeleteAtomicContent` is called with non editable text node, then it cannot
remove atomic content.
This fix doesn't follow other block case such as added newer test.
Differential Revision: https://phabricator.services.mozilla.com/D96298
Currently, this feature is implemented only on Linux and macOS (see also
bug 1077515 and bug 1301497), and the code is really similar each other.
Additionally, it always tries to query selection to check whether the caret is
in vertical content or not if arrow keys are pressed. For avoiding a lot of
query, this patch makes `TextEventDispatcher` cache writing mode at every
selection change notification. However, unfortunately, it's not available when
non-editable content has focus, but it should be out of scope of this bug since
it requires a lot of changes.
Anyway, with this patch, we can write a mochitest only on Linux and macOS.
The following patch adds a test for this as a fix of bug 1103374.
Differential Revision: https://phabricator.services.mozilla.com/D102881
Applying default edit action for some shortcut keys on Linux and macOS
causes some oranges. The new failure reasons are:
* The keyboard events are consumed in the bubbling phase of the system
group if editor has focus (`EditorEventListener` or `TextInputListener`
does it).
* No key combinations are mapped to per-word move or select on macOS.
* Home/End keys on macOS do not change selection.
Therefore, this adjusts each failure case for the new behavior.
Differential Revision: https://phabricator.services.mozilla.com/D102878
The issue is that the test was depending on the native resizers (or on a
previous test having loaded the non-native ones).
The first snapshot will not have resizers (because we just started the
load of the SVG) and thus following snapshots would fail.
Wait for the load event and pre-show the ltr textarea, so that the
resizer is known loaded.
This doesn't happen without the non-native theme because that uses
native resizers which don't depend on the image load.
Differential Revision: https://phabricator.services.mozilla.com/D103591
Masayuki Nakano
Butkovits Atila
Mirko Brodesser
Jonathan Kew
Makoto Kato
Brindusan Cristian
Csoregi Natalia
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Tom Schuster
Cameron McCormack