Bug 307340 – Selection jumps around when selecting absolutely-position elements inside non-selectable div

• Component: HTML Editing
• Status: RESOLVED FIXED

[Nicolò Ribaudo]

Created attachment 478290 [details]
selection_jump.html

I have a `<div>` with `user-select: none`. This div contains a bunch of text `<span>`s that have `position: absolute; user-select: text`. See the attached `selection_jump.html`.

Start selecting a word in the middle second `<span>`, and then expand the selection towards the right. Slightly move the cursor/finger up or down, not following the text exactly (which is likely to happen, especially on touch-screen devices). The selection will suddenly change to be from the beginning of the first `<span>` to the beginning of the original selection on the second `<span>`.

Try doing the same thing with the third/fourth span (you need to scroll to the bottom-left corner of the scrollable element): it has the same selection-jumping behavior. On Chrome for Android it's especially bad, as the scroll location jumps back to the top-left effectively making impossible to restore the correct selection by adjusting the finger position.

This is happening because the cursor/finger moves over the container `<div>`, so Chrome assumes that that means that the selection should move to the first child of it (the first `<span>` element), and on mobile it also makes sure to move that element to be visible.

While https://drafts.csswg.org/css-ui/ does not define what happens when during an ongoing selection the cursor moves over a `user-select: none` element, it says that:
> Attempting to start a selection in an element where user-select is none, such as by clicking in it or starting a drag in it, must not cause a pre-existing selection to become unselected or to be affected in any way.

It would be good behavior that dragging over the non-selectable element does not affect the existing selection.

This behavior is especially problematic when using https://www.npmjs.com/package/pdfjs-dist (the most popular web-based library for rendering PDFs), as it uses absolutely-positioned elements to render the PDF text in the right places.

The same happens on mobile when moving the carets, but unfortunately I could not figure out how to record my iPad's screen showing where my fingers are tapping.

I'm attaching:
- self-contained reproduction (`selection_jump.html`), also available at https://selection-jump-reproduction.nicolo-ribaudo.deno.net/
- a video of the Safari desktop behavior
- a video of the Firefox desktop behavior, which works as expected

[Nicolò Ribaudo]

Created attachment 478291 [details]
Firefox behavior

[Nicolò Ribaudo]

Created attachment 478292 [details]
Safari behavior

[Radar WebKit Bug Importer]

<rdar://problem/170475401>

[cathiechen]

Pull request: https://github.com/WebKit/WebKit/pull/59016

[EWS]

Committed 308451@main (fada263bd128): <https://commits.webkit.org/308451@main>

Reviewed commits have been landed. Closing PR #59016 and removing active labels.