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
According to the debug log and result on tryserver, the frequency of this
test failure becomes higher is caused by bug 1676966. When global reflow
is kicked during dragging the grabber, the implicit capture is released
forcibly. Fortunately, editor behavior shouldn't depend on font list
loading system, so, disabling the feature until fixing bug 1688430 is fine.
Differential Revision: https://phabricator.services.mozilla.com/D102889
This is same behavior as the other browsers. When selection is collapsed to
a edge of a link after deletion, we should stop applying link style to new
inserted content.
Differential Revision: https://phabricator.services.mozilla.com/D101006
When selection is not collapsed and is across link element boundary, we can
assume that user does not try to modify the link text because the other
browsers behave so. Therefore, we should take the same behavior in this case.
Note that all the new failures of `editing/run/inserttext.html` are passed
only on Gecko. So, it should be updated in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D101005
