Currently, its `mEditorWasDestroyed` is set to true even while `input` event
is being dispatched, i.e., even when it finished everything for the edit action.
However, the flag should be only for blocking unexpected cause which is caused
by mutation event listeners or something other unexpected event listeners
which shouldn't be run while editor is handling an edit action.
Therefore, this patch makes it store "handled" state which is marked before
notifying editor observers and dispatching `input` event and the flag won't
be set to true after it's marked as "handled".
Depends on D111579
Differential Revision: https://phabricator.services.mozilla.com/D111580
The editing session is temporarily disabled when opening a document. Then,
when the document is closed, the editing session is restored with same
`HTMLEditor` instance. Therefore, initializing editor may occur during
an edit action is being handled.
Probably, this must not be used in normal webapps since mutation events are
used rarely. So, I think that for avoiding further complicated things, we
should make editor won't accept new edit action handling after original
editing session ended.
This patch renames `AutoEditActionDataSetter::CanHandle()` to
`IsDataAvailable()` since it just checks whether the important resource is
available or not. And makes new `CanHandle()` return `false` for
non-initializing edit actions if editing session has ended.
Differential Revision: https://phabricator.services.mozilla.com/D111241
When given point is **in** a void element, e.g., this can be when JS inserts
nodes into a void element like `<meta>`,
`HTMLEditor::SplitNodeDeepWithTransaction` may return "not handled" state.
So, it's possible case, we shouldn't assert the case.
This patch adds both WPT and crashtests because I couldn't reproduce it
with WPT's simpler API use.
Differential Revision: https://phabricator.services.mozilla.com/D111231
When the method detects the style coming from a parent block, the `MOZ_ASSERT`
checks whether the current mode is "style with CSS" or not because currently,
`HTMLEditor` does not use `<span>` with CSS when the mode is not "style with
CSS". However, fixing it requires bigger patch, and the change does not match
with the bug's summary. So, I just remove the `MOZ_ASSERT`, add WPT and filed
bug 1649639 for the root issue.
Differential Revision: https://phabricator.services.mozilla.com/D111067
The lifetime of it is guaranteed by `AutoEditActionDataSetter` which grabs
`Selection` until it's destroyed, and it's a stack only class and created
at first step of all public method calls. Therefore, we can mark it as
`MOZ_KNOWN_LIVE` and we can change it returning reference of `Selection`
instead of reference of `RefPtr<Selection>`.
Differential Revision: https://phabricator.services.mozilla.com/D110896
Currently, it dispatches `input` event with holding `mPlaceholderTransaction`
and `mPlaceholerBatch` as 1. If `input` event listener sets value in XUL
document, the setting value transaction will break the existing placeholder
transaction. Then, only the last one will be undone, and it causes inserting
new padding `br` element with transaction and clears redo history.
This patch makes it forget them before dispatching `input` event.
Note that I tried to create automated test for this, but I cannot reproduce
this with simple testcase. I guess something other things also required to
reproduce this bug.
Differential Revision: https://phabricator.services.mozilla.com/D110715
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
Masayuki Nakano
Butkovits Atila
Mirko Brodesser
Jonathan Kew
Makoto Kato
Brindusan Cristian
Csoregi Natalia
Emilio Cobos Álvarez
Kagami Sascha Rosylight