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
