Closed Bug 1921705 Opened 1 year ago Closed 1 year ago

`Selection.modify()` from collapsed white-space only text node after `Selection.selectAllChildren(document.querySelector("[contenteditable]"))` causes putting caret into following non-editable text

Categories

(Core :: DOM: Selection, defect)

defect

Tracking

()

RESOLVED FIXED
133 Branch
Tracking Status
firefox133 --- fixed

People

(Reporter: masayuki, Assigned: masayuki)

References

()

Details

Attachments

(1 file)

STR

  1. Load https://jsfiddle.net/d_toybox/70jse21k/1/
  2. See the console

ER

The console shows: "focusNode=#text: \&quot; ;\&quot;, anchorNode=#text: \&quot; ;\&quot;". I.e., Selection should be collapsed in the text node after the non-editable <span>.

AR

The console shows: "focusNode=#text: \&quot;not editable\&quot;, anchorNode=#text: \&quot;not editable\&quot;", e.g., Selection is collapsed in the text node in the non-editable <span>.

If there is no getSelection().selectAllChildren(editingHost) call, it works. So, it seems that the call causes resetting the ancestor limiter.

Okay, it seems that selectAllChildren() causes setting caret hint to "after" and that changed the behavior.

Summary: `Selection.selectAllChildren(document.querySelector("[contenteditable]"))` makes `Selection` forget the ancestor limiter → `Selection.modify()` from collapsed white-space only text node after `Selection.selectAllChildren(document.querySelector("[contenteditable]"))` causes putting caret into following non-editable text

When PeekOffsetForCharacter find a non-editable content, it should never
return the frame because user must want to move caret only in editable content
when the previous position is editable. Additionally, when a non-selectable
frame is skipped, caret will be moved enough, so it should not skip any editable
content. Finally, the found frame may cause a line break. Therefore, this
patch overwrites the result of SelectablePeekReport::PeekOffsetForCharacter
from FOUND to CONTINUE_UNSELECTABLE when non-editable content is found.

The remaining failures of the new WPT should be handled in bug 449685 because
they are caused by no frame for invisible preceding/trailing white spaces around
the block element boundary.

Depends on D223909

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/755750429ced Make `nsIFrame::PeekOffsetForCharacter` treat non-editable frames as non-selectable r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48440 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 133 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: