1475232 - Up/Down causes cursor jump inside "contenteditable=true" with "display: flex" or "display: grid"

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Kevin Ansfield]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15

Steps to reproduce:

See basic reproduction case here: https://codepen.io/lookingsideways/pen/GBJWar

1. Create a `<div contenteditable="true" id="main"></div>` element
2. Apply flex styles to the div: `#main {display: flex; flex-direction: column}`
3. Add `<p>` child elements with text
4. Place the cursor in the contenteditable region
5. Use Up/Down arrow keys to move the cursor

Note that the following styling also demonstrates the problem: `#main {display: flex; flex-direction: row; flex-wrap: wrap}`


Actual results:

When the cursor reaches the edge of a child element the cursor jumps to the beginning or end (depending whether Up or Down key was pressed) of the whole contenteditable element.


Expected results:

The cursor moves naturally to the next vertical element. Chrome/Safari behave as expected.

Comment 1

[Daniel Holbert [:dholbert]]

The same thing happens for CSS Grid, too, FWIW: https://codepen.io/dholbert/pen/yqJMvY

Kinda good news: in both cases, the right/left-arrow keys *do* seem to move between sections naturally (to the next vertical element when pressed at the beginning/end of a section).  It's just the up/down-arrow keys that do a confusing thing.  So we've got the internal "previous/next" mapping correct, but our up/down logic just doesn't understand what is up/down.

Comment 2

[Makoto Kato [:m_kato]]

nsIFrame::PeekOffset with eSelectLine cannot found better frame (nsFrame::GetLineNumber cannot return better frame, or nsFrame::GetNextPrevLineFromeBlockFrame doesn't return NS_OK...). I suspect GetNextPrevLineFromeBlockFrame, but I don't know root cause.

Comment 3

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

If this occurs with non-editable elements in the caret browning mode, this should be moved to DOM: Selection component.

Comment 4

[martinh]

Attachment: Bug 1475232 - When next line selection moves to a valid frame without line iterator, drill down to a first selectable child with line iterator r?emilio

Also bug 1216483

The problem was that GetNextPrevLineFromeBlockFrame correctly identified the target frame but in case it was a flex/grid container, PeekOffsetForLine didn't accept it as a valid result due to a missing line iterator.

There was an existing case which handled this similarly for a table target, drilling into a first child with line iterator, but it was also incomplete.

Extended the drill condition for flex/grid and made the drilling algorithm more robust to be able to also crawl siblings and skip non-selectable elements (e.g. :before pseudoelement)

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/79ab209e5f29
When next line selection moves to a valid frame without line iterator, drill down to a first selectable child with line iterator r=emilio

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/79ab209e5f29

Comment 8

[Daniel Holbert [:dholbert]]

(Looks like this has a stale pending-needinfo -- canceling that.)