The testcase hits the assertion because `CreateNodeTransaction::DoTransaction()`
returns error, but it's not handled by `HandledInsertParagraphInParagraph()`
so that we should make `InsertBRElementWithTransaction()` and its callees
should return error if they meet unexpected cases.
Depends on D113471
Differential Revision: https://phabricator.services.mozilla.com/D113472
This changes the logic of `HTMLEditor::GetFirstEditableLeaf()` and
`HTMLEditor::GetLastEditableLeaf()`, but it shouldn't change actual behavior
because the case is that the first/last child of `aNode` is not in editing
host but editable.
Differential Revision: https://phabricator.services.mozilla.com/D113282
If the editor instance is a `TextEditor`, the root element has to be
anonymous `<div>` element and it has only one text node when it has non-empty
value. Therefore, if it's in `TextEditor`, the method does not need to use
the complicated APIs for finding a text node from the anonymous `<div>` element
or padding `<br>` element since it can adjust the given point into the text
node without such API.
Differential Revision: https://phabricator.services.mozilla.com/D113240
Only the user is `EditorBase::BeginningOfDocument()` which is used by both
`TextEditor` and `HTMLEditor`. However, if it's a `TextEditor`, expected
result is only the first text node only when there is one. Therefore, we can
move it into `HTMLEditUtils` and make `EditorBase::BeginningOfDocument()`
find the text node by it self. Then, we can get rid of using
`EditorBase::GetEditorType()` in this case.
Differential Revision: https://phabricator.services.mozilla.com/D113239
They are instance members of `EditorBase` only for referring editor type and
editing host. Therefore, we can make them static with making them take
editor type and ancestor limiter as arguments.
Depends on D113236
Differential Revision: https://phabricator.services.mozilla.com/D113237
The following patches will get rid of inline wrapper methods of them.
Therefore, they shouldn't be called as "internal". And they return
`nsIContent*` instead of `nsINode*` so, `Get*Content()` is better name for
them.
Depends on D113229
Differential Revision: https://phabricator.services.mozilla.com/D113230
So, the meaning is reverted of this action. But with this change, the scanner
methods scans any nodes by default. This is simpler to understand from the
callers.
Depends on D113228
Differential Revision: https://phabricator.services.mozilla.com/D113229
Before moving them from `EditorBase`, they should take only one option argument
whose type is an `EnumSet` class.
Note that I wanted to name each option for optional behavior, but
`FindAnyDataNode` requires to revert the its meaning (I.e., only with this
patch, `true` should be set an option). Therefore, the following patch renames
it.
Differential Revision: https://phabricator.services.mozilla.com/D113228
Like the other browsers, we shouldn't allow to user modify content in
`<select>` element. Note that this case won't occur with moving caret
with input devices. This occurs only with Selection API.
FYI: Chrome deletes `<select>` element if children of it are selected,
but it's odd behavior since user don't see where is selected visually
and may cause unexpected data loss (i.e., deleting `<select>` element).
Perhaps, we should investigate the behavior in other replaced elements
like `<textarea>` etc in follow up bugs.
Depends on D112513
Differential Revision: https://phabricator.services.mozilla.com/D112517
It's hard to understand each caller of `HTMLEditor::IsEmptyNode()` tries to
check with multiple `bool` arguments. Therefore, they should be replaced
with an `EnumSet`.
Note that only the first argument is reverted the meaning. Therefore, if
it's omitted or `false`, `EmptyCheckOption::TreatSingleBRElementAsVisible`
is specified explicitly. Otherwise, i.e., `true`, nothing should be
specified.
Differential Revision: https://phabricator.services.mozilla.com/D112513
It returns true only when it's a text node, but the text is empty.
However, `HTMLEditUtils::IsVisibleTextNode()` is used in
`HTMLEditor::IsEmptyNodeImpl()`. So, we replace it with directly using
`HTMLEditUtils::IsVisibleTextNode()`.
Depends on D112511
Differential Revision: https://phabricator.services.mozilla.com/D112512
I think that it's no matter to make `WSRunScanner` work without editing host.
Therefore, this patch make it take pointer of `Element` rather than reference.
Depends on D112502
Differential Revision: https://phabricator.services.mozilla.com/D112503
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
Matt Woodrow
Masayuki Nakano