1958985 - Can't use arrow up/down keys to land on an empty list item in contenteditable div

Status: RESOLVED FIXED

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Description

[David Shin[:dshin]]

Attachment: Reduced testcase

Noticed this on Slack.

STR:

1. Load attached test case
2. Put caret on upper "test" by clicking on it
3. Press down arrow, observe where the caret moves to
4. Put caret on lower "test" by clicking on it
5. Press up arrow, observe where the caret moves to
6. Put caret on middle bullet
7. Press either up/down arrow, observe where the caret moves to

Expected:

• Step 3: Moves to the first bullet
• Step 5: Moves to the last bullet
• Step 7: Moves to the first (up)/last (down) bullet

Actual:

• Step 3: Moves to the upper test
• Step 5: Moves to the lower test
• Step 7: Moves to the upper (up)/lower (down) bullet

Comment 1

[Jonathan Kew [:jfkthame]]

It's not purely about empty list items, even:

1. Load the testcase
2. Click to the caret on each bullet in turn, and insert the words "one", "two", "three" on the respective lines
3. Click to put the caret in the middle of the upper word "test"
4. Press down-arrow

Expected: caret moves to the beginning of the first list item
Actual: caret jumps past the list items to the lower "test"

5. Now add text to the top line so that it reads "test for caret movement with arrow keys"
6. Click in the middle of the word "keys"
7. Press down-arrow

Expected: caret moves to the end of the first list item (maintaining its horizontal position, as far as possible within the line)
Actual: works as expected

So the problem occurs when the horizontal offset of the caret is before the start of the list-item text.

And it only occurs when the list-item's ::marker has display: inline-block; changing it to display: inline resolves the issue.

Similar behavior can be reproduced with other kinds of generated content having inline-block display, e.g. with

data:text/html,<style>blockquote::before{content:"*";display:inline-block}</style>
    <div contenteditable>test<blockquote>quote</blockquote>test</div>

up/down arrows will move the caret directly between the two "test" lines, skipping the indented blockquote.

The same thing happens if the "target" caret position is past the end of a line, and it ends with generated content having display: inline-block. Example:

data:text/html,<style>blockquote::after{content:"*";display:inline-block}</style>
    <div contenteditable>test for caret movement<blockquote>quote</blockquote>test</div>

Put the caret at the end of the word "movement" and press down-arrow; it skips past the "quote" to end of the third line.

Comment 2

[Jonathan Kew [:jfkthame]]

What's happening seems to be that the search in nsIFrame::PeekOffsetForLine ends up descending into the inline-block frame found at the beginning or end of the potential target line; but then it determines that it's not a valid result because it is generated content; so the search fails on that line, and moves on to the next.

We should prevent the search descending into the generated-content block, and let it try the next (or previous) frame on the line instead.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1958985 - Don't allow a generated-content block as a "result frame" in GetNextPrevLineFromBlockFrame. r=#layout

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/82da936a0e11
Don't allow a generated-content block as a "result frame" in GetNextPrevLineFromBlockFrame. r=layout-reviewers,emilio

Comment 5

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/82da936a0e11

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/52089 for changes under testing/web-platform/tests

Comment 7

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot