If given `nsPresContext` is for a lazy loading `<iframe>` and the frame has not
been loaded yet, its `GetTextInputHandlingWidget()` may return `nullptr`.
However, `IMEStateManager::sTextInputHandlingWidget` may have already cache it.
Therefore, `IMEStateManager` should use:
* `sTextInputHandlingWidget` if it's available
* otherwise, `nsPresContext::GetTextInputHandlingWidget()`
Differential Revision: https://phabricator.services.mozilla.com/D197991
The method does not assume that an inline ancestor is not a splittable, but
it may occur in the edge cases.
I tried to make `HTMLEditor` adjust selection range at starting deletion to
stop handling it or select the most distant unmodifiable element, but it
requires some expectation changes of tentative WPTs. It should be done in
a separate bug instead.
Differential Revision: https://phabricator.services.mozilla.com/D198345
`beforeinput` event shouldn't be fired if it's caused by JS. However, we
dispatch it when the call is by chrome script or an addon because there is
no user input emulation API for WebExtension and builtin editors make the
change undoable only when JS changes the editor value with
`Document.execCommand`. Therefore, addons may want to use
`Document.execCommand` for making the change undoable.
On the other hand, nested calls of `Document.execCommand` makes the error
handlings in editor classes too complicated. Therefore, we don't allow that.
However, this causes that if web apps intercept `beforeinput` events and
prevents the default and calls `document.execCommand`, the first call of
web apps may be first nested call if the `beforeinput` event is caused by
a call of `Document.execCommand` in addon.
Therefore, this patch makes `Document` stores whether `ExecCommand` is called
by content or chrome/addon. And if the call is improperly nested, keep stopping
handling the command, but allows if and only if the first call is by
chrome/addon.
Differential Revision: https://phabricator.services.mozilla.com/D198357
The test case removes entire the `<output>` during deleting its content and
that occurs during it moves the content in `<div>` into the preceding `<ruby>`.
Therefore, the destination becomes not connected to the document so that it
fails to track the range of moved contents in the document.
Then, the code does not explicitly mark the caret position is not necessary.
So, we just need to do it.
Differential Revision: https://phabricator.services.mozilla.com/D198148
Invalid children of `<picture>` like text may appear as usual. Therefore,
they should be editable.
Note that this patch does not fix the root cause of the assertion because
if selection range may cross a remaining element boundary listed in the
method, but I couldn't find a way to fix this with a reasonable size patch.
Differential Revision: https://phabricator.services.mozilla.com/D197988
Oddly, it returns the latest result as split result. However, in the case,
it splits `<kbd>` under `<button>`, but does not split `<button>`, but the
caller expects that whether it did split or not.
Differential Revision: https://phabricator.services.mozilla.com/D197262
It treats non-editable content as invisible. Therefore, if you try to
delete backward/forward from first/last block, Gecko deletes the block with
the non-editable content.
Depends on D196817
Differential Revision: https://phabricator.services.mozilla.com/D196819
Pasting and inserting HTML clears current style to respect the new style.
Therefore, the old ancestors shouldn't be removed when they have only
non-editable content.
Unfortunately, I have no idea how to test all of the paths which are changed
by this patch. However, I believe the method should always treat non-editable
content as visible.
Differential Revision: https://phabricator.services.mozilla.com/D196817
If the parent block has only non-editable, it treat the block as invisible and
puts `<br>`. Therefore, deleting content may cause inserting new line in some
cases.
Depends on D196814
Differential Revision: https://phabricator.services.mozilla.com/D196815
When it cleans up unnecessary new empty inline ancestors, it should treat
non-editable elements in the inline containers as visible.
Depends on D196813
Differential Revision: https://phabricator.services.mozilla.com/D196814
It means that "treat non-editable things as visible" when it's not set.
However, it's odd. You must assume that if no option is set, `IsEmpty()` etc
should treat non-editable nodes as visible things. Therefore, this renames it
to `TreatNonEditableContentAsVisible` and changing all callers of
`HTMLEditUtils::IsEmptyNode`, `HTMLEditUtils::IsEmptyInlineContainer`,
`HTMLEditUtils::IsEmptyBlockElement` and
`HTMLEditUtils::CollectEmptyInlineContainerDescendants`. So, this does not
change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D196813
It allows multiple edit action preserves `Selection` when updating the DOM tree.
However, most callers do not use `finally` to reset the state, and this makes
edit action handling complicated in some edge cases. Therefore, let's stop
supporting this feature. If Thunderbird requires the feature, the developers
should request additional param for preserving `Selection` like the preceding
patch.
Depends on D196004
Differential Revision: https://phabricator.services.mozilla.com/D196005
`nsIEditor.setShouldTxnSetSelection` can preserve selection across multiple
editing. Therefore, we cannot manage the state only in the stack.
It's used only in comm-central, and used only with `insertNode` and
`deleteNode`. Therefore, adding new param to them to preserve selection
must be enough.
While I'm writing this patch, I realized that `input` event is not fired
by these methods because nobody set a placeholder transaction. That may
lead Thunderbird only IME crash bugs due to `IMEContentObserver` is not
notified editor properly. Therefore, this may fix some Thunderbird only
crashes.
Note that `deleteNode` should not update selection. However, I'm not 100%
sure that. Therefore, I add new param to `deleteNode` too. However,
some reviewers think it's unnecessary, I'll remove it before landing.
Finally, `beforeinput` and `input` caused by the method calls start updating
selection. However, I think that it should be better behavior. If Thunderbird
needs to guarantee that selection is set to whether the user expected when
it calls these methods with preserving selection.
Differential Revision: https://phabricator.services.mozilla.com/D196004
The text input of the multi-select combobox of Slack has the following
structure:
```
<div contenteditable style="display:flex">
<span class="c-multi_select_input__space"> </span>
<span class="c-multi_select_input__filter_query">text which you typed</span>
<span class="c-multi_select_input__space" contenteditable="false"> <span>
</div>
```
When you do "Select All", they adjust selection to start from start of the
text container `<span>` (i.e., `.c-multi_select_input__filter_query`).
Then, typing new character deletes selection first. At this time, in the
legacy mode, `AutoDeleteRangesHandler::ExtendOrShrinkRangeToDelete` does not
extend the deleting range because `<span>` is an inline element. However,
in the new mode, it extends the range because the `<span>` is a block since
it's a flex-item, and selection starts from current block boundary. Then,
deleting range starts before the text container. Finally, Gecko removes the
text container and the following non-editable `<span>`. Therefore, typing text
will be inserted as a child of the flex container which is the editing host.
Finally, Slack restores the previous structure and collapse selection to end
of the text.
Currently, Chrome does same thing for normal blocks without flex/gird container.
However, doing i in `AutoDeleteRangesHandler::ExtendOrShrinkRangeToDelete`
causes a lot of regressions. Therefore, this patch tries to avoid only the bug
in Slack. (I think that we need to redesign the deletion handler to fix it.)
Differential Revision: https://phabricator.services.mozilla.com/D195955
This is tested via the inert tests, effectively, but I can add more
explicit tests.
Remove rules that would otherwise change behavior (the other rules in
the tree apply to XUL elements and serve a purpose).
Differential Revision: https://phabricator.services.mozilla.com/D195645
Chrome handles text direction change as a block level format command. I.e.,
Chrome sets `dir` attributes of enclosing editable blocks of selected leaf
nodes. However, aligning to this may require a lot of change and Thunderbird
may require the traditional behavior.
On the other hand, it's obviously wrong thing that `Ctrl` + `Shift` + `X` in an
editable element changes the direction of entire the document since the `<body>`
may not be editable.
Therefore, this patch just changes the direction change target from `<body>`
to active editing host if it's an `HTMLEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D195838
`AutoMoveOneLineHandler` uses `AutoRangeArray` API for block level edit
sub-actions. Therefore, the source line is computed with
`BlockInlineCheck::UseHTMLDefaultStyle`. However, the deletion handler works
with `BlockInlineCheck::UseComputedDisplayOutsideStyle`. Therefore,
`AutoMoveOneLineHandler` may try to move different range. In the reported
test case, it tries to move all content under the `<body>` into the
`<a display="table-header-group">` which is contained in the range. Therefore,
the `movedContentRange` check fails after the destination becomes into an
orphan node which was removed to move.
This patch renames the API and adds a `BlockInlineCheck` parameter to work
with both ways and makes `AutoMoveOneLineHandler` specify
`BlockInlineCheck::UseComputedDisplayOutsideStyle` as same as the other delete
handlers.
Finally, same thing may happen in
`HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal`. This patch makes it
check whether the top-level edit sub-action is a block level one or not and
consider `BlockInlineCheck` with the result.
Depends on D194180
Differential Revision: https://phabricator.services.mozilla.com/D194181
The class does complicated things and has been reported some assertion failures.
For making the debug faster, let's add the logging code.
Differential Revision: https://phabricator.services.mozilla.com/D194180
In the fallback code for native key bindings and in the inline table handling,
the editor still use `GetDOMEventTarget()` and `IsInUncomposedDoc()` which are
not aware of shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D193621
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
This is a simple mistake of the previous patch. The code path is originally for
a left click handling. Therefore, there is no check whether the click point is
in a selection range because in that case, left click should collapse selection.
However, the selection should not be collapse when it's a right click in a
selection range because the context menu target is the selection range.
The `ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection`
pref is set to `true` by default. Therefore, the existence of a non-collapsed
selection has hidden this bug. However, if it's set to `false`, this always
happens. Additionally, editor does not set ancestor limiter of selection if the
root element is editable [1]. I think that we can now remove this special path,
but it's risky. Therefore, this patch just adds the new check into the method.
1. https://searchfox.org/mozilla-central/rev/ce4599d3d4e20e34cb6db68f255c3dff1aec246b/editor/libeditor/EditorBase.cpp#5448,5450-5451
Differential Revision: https://phabricator.services.mozilla.com/D193529
They check ancestor limiter when they are climbing up the DOM tree if and only
if the ancestor does not have a sibling. However, this causes moving into
a sibling of the ancestor limiter.
Differential Revision: https://phabricator.services.mozilla.com/D192528
Gecko starts referring computed style to consider whether block or inline and
`HTMLEditUtils::IsEmptyNode` is used with them to check a node like these:
https://searchfox.org/mozilla-central/rev/40d51bef58b8e901d6ab4b60dd280f372a0e417d/editor/libeditor/HTMLEditUtils.h#543,554
However, `IsEmptyNode` still checks only the tag names when the caller wants
to treat "list items" and/or "table cells" are visible (not empty). Therefore,
this mismatch may cause the assertion failure reported in the bug.
From code design point of view, `HTMLEditUtils::IsListItem` and
`HTMLEditUtils::IsTableCell` should refer the computed style. However, the
former is mostly used for checking the logical structure of HTML, and in the
latter case, we should keep the table structure even if table cells are styled
as inline because browsers do not support table structure recreation except
the Gecko specific editing UI (called inline table editor). Therefore, it does
not make sense that we would change them.
Instead, we should change `IsEmptyNode` which is used only for visibility check.
So, using computed style is always reasonable.
Note that this patch changes the behavior in some edge cases. The method always
treat a list item or a table cell which contains a sub-list or a sub table.
However, I would not like to add new `EmptyCheckOption` for it to check the
complicated style check. Therefore, this patch changes the behavior to treat
them visible if and only if they have another list item or another table cell.
Basically, `<table>` and list elements should have a least one table cell or
one list item. Therefore, this change should not appear in the web apps in the
wild.
Differential Revision: https://phabricator.services.mozilla.com/D192442
It moves nodes in a range to new place one by one. At this time, the moved
position range is not tracked. Therefore, if the DOM tree is unexpectedly
changed by `HTMLEditor` itself, the range gets broken. E.g., in this case,
deleting empty inline element causes the range after the source position is
broken.
Differential Revision: https://phabricator.services.mozilla.com/D192180
Now, all callers of them do not require to check `<dl>`, `<dt>` and `<dd>` check
if it's in the HTML format block mode. Therefore, we can move the check into
`HTMLEditor::IsFormatElement` to make the caller side simpler.
Additionally, this patch replaces some places with
`HTMLEditUtils::IsFormatElementForParagraphState` because the paths handle only
XUL paragraph state command with assertion check.
Depends on D190902
Differential Revision: https://phabricator.services.mozilla.com/D191604
Currently, we extend selection to outside block boundaries if selection starts
and/or ends very start/end of block boundaries. Then, replace most-distant
ancestor format node, but this is odd because the innermost format is applied
to the text and the other browsers targets the innermost ancestor formant node.
Therefore, we should align to them.
Additionally, our replacing code for `<dd>` and `<dt>` has not been implemented
yet. I guess that the old `HTMLEditUtils::IsFormatNode` returned `false` for
`<dd>`, `<dl>` and `<dt>` and it requires additional work for splitting parent
`<dl>` too. Now, we can do it with simple code.
Finally, we created new format block element if `<br>` element appears, but
the other browsers moves it into the new format node simply. Therefore, we
should follow them (about `<blockquote>`, we've already done this within
the different path).
Differential Revision: https://phabricator.services.mozilla.com/D190902
`Document.execCommand` accepts `dl`, `dt` and `dd` as a format block. However,
`ParagraphStateAtSelection` ignores them as not a format block element.
Therefore, it causes odd result of `queryCommandValue` after applying the
format. E.g., `execCommand("dd")` to `<p>[foobar]</p>` correctly updates the
HTML to `<dl><dd>foobar</dd></dl>`, however, `queryCommandValue("dd")` returns
empty string rather than `dd`.
Note that Chromium returns inclusive ancestor format element of common ancestor
of the range. However, the behavior is odd because it makes the indeterm
state never `true` and the result is not used as the target of format block
command. So, this patch does not follow them at least for now.
On the other hand, this patch adds special case for `dl`. With user's
operation in valid HTML structure, selection range never selects `<dl>`
children directly. However, may cross `<dt>` and `<dd>` elements.
Then, let's return `dl` for compatibility with Chromium because `<dl>`
ancestor may be the format block target.
Differential Revision: https://phabricator.services.mozilla.com/D190901
I realized that our `HTMLEditUtils::IsFormatNode` is not maintained different
from the other browsers. Therefore, only we do not check new elements defined
after HTML 4.01. This patch aligns the list of the format elements to the
others [1].
Then, this also changes some expectations of `editing/run/formatblock.html`
to align common behavior of the browsers.
Note that we mapped `formatBlock` of `execCommand` to `cmd_paragraphState`,
and the XUL command handles `<blockquote>` in a different path [2] and the
behavior is pretty different from the other formatBlock command implementations.
Therefore, this patch creates new command for `formatBlock` and makes
`HTMLEditor` switch behavior in any places.
1. ba50f40fc4:third_party/WebKit/WebCore/editing/FormatBlockCommand.cpp;l=114-134
2. https://searchfox.org/mozilla-central/rev/6602bdf9fff5020fbc8e248c963ddddf09a77b1b/editor/libeditor/HTMLEditor.cpp#2461-2474
Differential Revision: https://phabricator.services.mozilla.com/D190900
The handler has an early-return block for the case inserting empty text.
However, it's done before deleting selection, but it should be done after that.
Differential Revision: https://phabricator.services.mozilla.com/D190904
This makes number localization cheaper / halves the time in the
microbenchmark.
Change the content-language handling to use atoms. This exposes some
interesting inconsistencies but I tried not to change behavior there.
Differential Revision: https://phabricator.services.mozilla.com/D191174
As the comment in the method, `CurrentBlockBoundary` may be set when `mContent`
is not a block. However, it's not allowed that there is an editable block
ancestor of `mContent` in same editing host (in this case, `mContent` should be
the block). Therefore, it should compute ancestor block element and check
whether it's not in same editing host if `mContent` is editable and connected.
Differential Revision: https://phabricator.services.mozilla.com/D190644
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
This patch is related to Bug 1840822, which fixes some issues
regarding additional invisible linebreaks needed at the end of
contenteditables.
This patch in particular fixes the case where the user
presses enter at the end of a pre-formatted
contenteditable, e.g.:
```
<span contenteditable style="display:block;white-space:pre-line">[]</span>
```
Prior to this patch, only one `<br>` was added,
the invisible padding linebreak was missing.
With this patch applied, the behaviour should be as expected:
```
<span contenteditable style="display:block;white-space:pre-line">\n<br></span>
```
Differential Revision: https://phabricator.services.mozilla.com/D190217
The other browsers move focus and `Selection` whe right click even if the
clicked element is not editable and even if there is a non-collapsed selection.
Fortunately, we already have similar code for the middle button press.
Therefore, we can make it run when the pressed button is the secondary button.
This also fixes bug 416546 and does not resurrect bug 709476.
However, this patch adds 2 prefs for making users customizable. Our traditional
behavior is, we never collapse non-collapses selection with a right click even
if clicked outside the selection. This allows users to open context menu for
selected text much easier. Therefore, even though the behavior is different
from the others, we should keep the traditional behavior, but some users may
want the other browsers' behavior instead. For them, this should be switchable
by a pref.
Additionally, I'm still not sure collapsing selection with a right click in
non-editable content especially for users using the caret browsing mode.
Therefore, for making things safer, this adds a pref to disable the new behavior
in the non-editable content.
Differential Revision: https://phabricator.services.mozilla.com/D189991
If `HTMLEditor::HandleInsertBRElement` inserts an invisible `<br>` element
after a `<br>` element which is requested, new caret position should be
at the invisible `<br>` element.
Differential Revision: https://phabricator.services.mozilla.com/D189997
Without this patch, the following test newly fails:
```
/editing/other/insertparagraph-with-white-space-style.tentative.html?white-space=nowrap&command=insertText
FAIL <div contenteditable style="white-space:nowrap; display:inline">abc[]</div> (defaultparagraphseparator: div) - assert_equals: A <br> should be inserted at end expected "abc<br><br>" but got "abc<br>"
FAIL <div contenteditable style="white-space:nowrap; display:inline">abc[]</div> (defaultparagraphseparator: p) - assert_equals: A <br> should be inserted at end expected "abc<br><br>" but got "abc<br>"
```
The reasons is, the inlined editing host is at end of the `<body>`, therefore,
even though the editing host itself is `inline`, it needs a padding `<br>` to
make it the new line visible.
However, `HTMLEditUtils::GetElementOfImmediateBlockBoundary` does not return
`<body>` because the editing host is followed by `<script>` which has
a text node which is not white-spaces only. Therefore,
`HTMLEditUtils::IsVisibleBRElement` considers the `<br>` element at end of the
editing host is "visible".
Differential Revision: https://phabricator.services.mozilla.com/D188599
Blink [1] and WebKit [2] refers `display-outside` value when they consider whether an
element is a block or an inline.
However, our editor refers HTML default style instead. Therefore, our editor
cannot handle the following cases:
* If a container block is a non-HTML element whose `display` style is `block`.
* If a container `<div>` etc is styled as `inline` and typing `Enter` in it.
* If a container `<span>` is styled as `block` and it ends with spaces.
For making users get better result, we should follow the other browsers.
However, this is too risky change. Therefore, this patch enables new behavior
only in the Nightly channel and early beta builds to collect feedback from
testers.
The big rules of checking block vs. inline are:
* When we handle block level edit actions such as formatting block, indenting
or outdenting selection, making or removing list, we should keep referring
the HTML default style because the other browsers do so and the commands are
intended for modifying the HTML structure.
* Otherwise, we should refer the computed style of the block. However, if
working with non-connected elements, we may need a special handling that is
falling back to refer the HTML default style because `HTMLEditorDataTransfer`
work with non-connected document fragments.
* Finally, if we check visibility of collapsible white-spaces and `<br>`s, we
should refer computed style. However, in this case, we may need to treat
ancestor `inline-block`s as block too, but for siblings, we should refer only
`display-outside`.
1. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/editing_utilities.cc;l=779;drc=31fb07c05718d671d96c227855bfe97af9e3fb20
2. https://searchfox.org/wubkat/rev/b054636fffeffa0314914a11ce39725a3057131e/Source/WebCore/editing/Editing.cpp#317
Differential Revision: https://phabricator.services.mozilla.com/D188598
This didn't work properly for non-native key bindings because:
https://hg.mozilla.org/mozilla-central/rev/8934e6e6ccb6
Moved the DetachedFromEditorOrDefaultPrevented() check before the "hide
cursor" check, rather than after. This was a quick fix, because if we're
detached from the editor, then GetPresContext would assert. But I didn't
realize at the time (since it was a long time since I wrote the patch)
that most events there actually are default-prevented.
To fix this, split the checks. Checks for DetachedFromEditor() first,
and only after potentially hiding the cursor check whether the event is
default-prevented.
Differential Revision: https://phabricator.services.mozilla.com/D187536
The new join/split node direction mode seems working well in the wild because
we have no regression reports about it. Therefore, we won't revert the pref
anymore, thus, the legacy mode behavior check is not required.
Differential Revision: https://phabricator.services.mozilla.com/D186680
It returns the result of
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()`, but it suggests
caret position only when it modifies the DOM tree since it does not take the
default caret position.
So, `DeleteContentNodeAndJoinTextNodesAroundIt()` does need to return
`aCaretPoint` with tracking it during DOM mutations if
`MakeSureToKeepVisibleStateOfWhiteSpacesAroundDeletingRange()` does not
suggest caret point.
I found this bug when I was trying to fix the unexpected failing of
forward delete at end of the last block in the editing host (bug 1850666)
because changing the error handling anyway cause another error at this line.
https://searchfox.org/mozilla-central/rev/bdd5b85b56885cd48bd91d262647e0d3499b3a27/editor/libeditor/HTMLEditorDeleteHandler.cpp#1652
Therefore, without fixing bug 1850666, I have no idea how to check this fix.
Differential Revision: https://phabricator.services.mozilla.com/D187196
This only hides the cursor if it's on the page you're editing, but given
that the point of the feature is to move the cursor out of the way, that
seems acceptable (and honestly it feels more of a feature than a bug).
This should work across platforms (though non-windows platforms need
ui.hideCursorWhileTyping=1 in about:config to enable).
Differential Revision: https://phabricator.services.mozilla.com/D171155
This one is tricky because form controls, though I think I got it right...
This fixes a pre-existing bug where we're not following the spec for readonly
inside content-editable.
I filed this as bug 1850390 but other browsers match the spec so add a test and
fix it while at it. This allows cheaper checks for readonlyness in a couple
places.
Differential Revision: https://phabricator.services.mozilla.com/D186896
It does nothing in most cases because it inserts a `<br>` element only when
the editable `<body>` does not have meaningful content. Therefore, we can
make it put off to create `AutoEditSubActionNotifier` to save the cost of
some expensive things done by `OnStartToHandleTopLevelEditSubAction()` and
`OnEndHandlingTopLevelEditSubAction()`.
Differential Revision: https://phabricator.services.mozilla.com/D186514
A lone surrogate should not appear in `DOMString` at least when the attribute
values of events because of ill-formed UTF-16 string.
`TextEventDispatcher` does not handle surrogate pairs correctly. It should not
split surrogate pairs when it sets `KeyboardEvent.key` value for avoiding the
problem in some DOM API wrappers, e.g., Rust-running-as-wasm.
On the other hand, `.charCode` is an unsigned long attribute and web apps
may use `String.fromCharCode(event.charCode)` to convert the input to string,
and unfortunately, `fromCharCode` does not support Unicode character code
points over `0xFFFF`. Therefore, we may need to keep dispatching 2 `keypress`
events per surrogate pair for the backward compatibility.
Therefore, this patch creates 2 prefs. One is for using single-keypress
event model and double-keypress event model. The other is for the latter,
whether `.key` value never has ill-formed UTF-16 or it's allowed.
If using the single-keypress event model --this is compatible with Safari and
Chrome in non-Windows platforms--, one `keypress` event is dispatched for
typing a surrogate pair. Then, its `.charCode` is over `0xFFFF` which can
work with `String.fromCodePoint()` instead of `String.fromCharCode()` and
`.key` value is set to simply the surrogate pair (i.e., its length is 2).
If using the double-keypress event model and disallowing ill-formed UTF-16
--this is the new default behavior for both avoiding ill-formed UTF-16 string
creation and keeping backward compatibility with not-maintained web apps using
`String.fromCharCode`--, 2 `keypress` events are dispatched. `.charCode` for
first one is the code of the high-surrogate, but `.key` is the surrogate pair.
Then, `.charCode` for second one is the low-surrogate and `.key` is empty
string. In this mode, `TextEditor` and `HTMLEditor` ignores the second
`keypress`. Therefore, web apps can cancel it only with the first `keypress`,
but it indicates the `keypress` introduces a surrogate pair with `.key`
attribute.
Otherwise, if using the double-keypress event model and allowing ill-formed
UTF-16 --this is the traditional our behavior and compatible with Chrome in
Windows--, 2 `keypress` events are dispatched with same `.charCode` values as
the previous mode, but first `.key` is the high-surrogate and the other's is
the low surrogate. Therefore, web apps can cancel either one of them or
both of them.
Finally, this patch makes `TextEditor` and `HTMLEditor` handle text input
with `keypress` events properly. Except in the last mode, `beforeinput` and
`input` events are fired once and their `data` values are the surrogate pair.
On the other hand, in the last mode, 2 sets of `beforeinput` and `input` are
fired and their `.data` values has only the surrogate so that ill-formed
UTF-16 values.
Note that this patch also fixes an issue on Windows. Windows may send a high
surrogate and a low surrogate with 2 sets of `WM_KEYDOWN` and `WM_KEYUP` whose
virtual keycode is `VK_PACKET` (typically, this occurs with `SendInput` API).
For handling this correctly, this patch changes `NativeKey` class to make it
just store the high surrogate for the first `WM_KEYDOWN` and `WM_KEYUP` and use
it when it'll receive another `WM_KEYDOWN` for a low surrogate.
Differential Revision: https://phabricator.services.mozilla.com/D182142
This patch deals with this case:
```
<span contenteditable><div>foo</div>[]</span>
```
In this case only one `<br>` should be added since one
line break is already added because of the `<div>` block.
Differential Revision: https://phabricator.services.mozilla.com/D185935
The logic behind this patch is similar to that of part 1, only that this covers the case where a user triggers a line break instead of a new paragraph (i.e. by pressing [Shift/cmd]+[Enter]).
If the inserted BR element is followed by a block boundary, another BR element is added.
Depends on D182339
Differential Revision: https://phabricator.services.mozilla.com/D182485
If a user presses <Enter> to add a new paragraph at the end of a contenteditable, a second (invisible) line break has to be added:
`<span contenteditable>foo[]</span>` --> `<span contenteditable>foo<br><br></span>`
This patch deals with contenteditables which do not preformat whitespaces
(i.e. should insert linebreaks, not linefeeds).
The linefeed cases are handled in Bug 1840856.
Also this patch only deals with a code path that uses `insertParagraph`.
The code path that uses `InsertLineBreak` is handled in part 2 of this Bug.
The patch implements a lambda function that inserts a second `<br>` element,
which is called in two situations:
1. The editing host is empty:
`<span contenteditable>[]</span>`--> `<span contenteditable><br><br></span>`
2. The caret is at a block boundary:
`<span contenteditable>abc[]</span>` --> `<span contenteditable>abc<br><br></span>`
Differential Revision: https://phabricator.services.mozilla.com/D182339
Calling `UpdateDefaultPreventedOnContent` separately from
`PreventDefault()` is error-prone. This patch should make it
safer.
Differential Revision: https://phabricator.services.mozilla.com/D186052
`ContentEventHandler` works with `PostContentIterator` and `PreContentIterator`
when it scans DOM nodes in a range. While iterating the DOM nodes, script
never runs. Therefore, we can make `ContentEventHandler` work with new
content iterators which do not store nodes with strong pointers.
This patch makes `ContentIteratorBase` a template class and create new
`UnsafePostContentIterator` and `UnsafePreContentIterator`. They will
check whether DOM mutation or GC occurs before destruction to detect dangerous
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D184441
Implemented the new <search> HTML element.
All WPT tests for it now pass (except one for iso-8859-8, not done generally).
A11y role uses just landmark as recommended instead of a new search role (for now).
Co-authored-by: Henri Sivonen <hsivonen@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D176967
Masayuki Nakano
Tooru Fujisawa
Jeff Muizelaar
Emilio Cobos Álvarez
Jonathan Watt
Cristian Tuns
Divyanshu Agrawal
Ajay
Mark Banner
Edgar Chen
Sylvestre Ledru
Cristina Horotan
Tom Marble
Natalia Csoregi
Noemi Erli
Jan-Niklas Jaeschke
serge-sans-paille
Jan Varga
Joel Maher
Olli Pettay
pommicket
Cosmin Sabou
Gregory Pappas
Makoto Kato
Sean Feng
CanadaHonk
Stanca Serban