1820290 - Unexpected image block included in selection of single word

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect, P2)

Description

[Timo Tijhof]

Attachment: firefox-110-mac.png

Given an image followed by a block-level element containing mutiple words, I expect that double-clicking a word will select only that word. This works as expected in Safari and Chrome. It also, usually, works that way in Firefox (tested on macOS and Windows).

In certain cases, when a floated element sits in front of the text, for unclear reasons the text selection grows over this floated element and then goes beyond to include the preceeding image block.

Test case: https://codepen.io/Krinkle/pen/PodmgKy?editors=1100

div: IMAGE
div:
- One Two Three Words
- [icon float right]

In this case, double-clicking "One" selects "One" only.

div: IMAGE
div:
- [icon float right]
- One Two Three Words

In this case, only in Firefox, double-clicking "One" selects both "One" and the icon (OK), and and the preceeeding "Image" block.

I've confirmed the issue in Firefox 110 (latest stable, macOS) and Firefox 111 (Beta, Windows 8 via BrowserStack).

The affected markup is how Wikipedia renders image captions for the past ten years. For example, double-clicking the first word in the image caption on https://en.wikipedia.org/wiki/Survivorship_bias produces this bug.

Comment 1

[Timo Tijhof]

Attachment: firefox-111-beta-windows.png

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Masayuki, do you know what's up in this particular case? Though I am not quite sure if I will think this is a S2, given that users can have a workaround to select a single word by drag-n-drop.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that it's a bug of nsIFrame::GetFrameFromDirection which I'm touching in bug 1384606. When searching a character or word boundary, it should stop when such image frame is found. However, it might be intentionally ignored in some cases, e.g., 0-sized images, etc. Therefore, need to investigate whether it's intentional first.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Talked with Masayuki, downgrading to S3 - it's inconvenient to users in some cases but workaround exists by drag-n-drop.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1820290 - Make `nsIFrame` treat out-of-flow things as word separators r=emilio!

Out-of-flow creates nsPlaceholderFrame, and nsIFrame::PeekOffset related
methods treat words can cross its boundaries. However, it looks odd that a
sequence of content split by nsPlaceholderFrame is treated as a word.

Therefore, I think that nsIFrame::IsLogicallyAtLineEdge and
nsIFrame::IsVisuallyAtLineEdge should ignore placeholder to check whether the
frame is first/last of the line.

Additionally, I think that nsIFrame::PeekOffsetForWord should not allow
nsIFrame::GetFrameFromDirection to cross nsPlaceholderFrame boundaries
if it's already found some characters.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1820290 - Rename `PeekOffsetOption::ScrollViewStop` for consistency r=emilio!

Depends on D176250

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f93ca11cb555
Make `nsIFrame` treat out-of-flow things as word separators r=emilio
https://hg.mozilla.org/integration/autoland/rev/2ece04e240e2
Rename `PeekOffsetOption::ScrollViewStop` for consistency r=emilio

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/f93ca11cb555
https://hg.mozilla.org/mozilla-central/rev/2ece04e240e2