Bug 105898 – contenteditable contains DIV's with display: inline-block breaks up and down arrows

• Component: HTML Editing
• Status: NEW

[Yermo]

The following HTML:

<div contenteditable="true">
test
<div style="display: inline-block;">
    <div style="font-weight: bold">Click here. Why does down arrow now work?</div>
</div>
test
<div>
test
<div style="display: inline-block;">
    <div style="font-weight: bold">TEST2</div>
</div>
Click mouse here and press up arrow in chrome? Why does it not go up?
</div>
</div>

causes the UP and DOWN arrows to fail in Chome.

See: http://stackoverflow.com/questions/14108115/chrome-divs-with-display-inline-block-breaks-up-and-down-arrows#comment19525253_14108115

[James Fisher]

This is still a bug here in 2021. See my minimal test case: https://codepen.io/jameshfisher/pen/KKvWoEe

Here is the corresponding bug report in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1088403

Can someone at least mark the status as "CONFIRMED"?

[Ahmad Saleem]

(In reply to James Fisher from comment #1)
> This is still a bug here in 2021. See my minimal test case:
> https://codepen.io/jameshfisher/pen/KKvWoEe
> 
> Here is the corresponding bug report in Chromium:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1088403
> 
> Can someone at least mark the status as "CONFIRMED"?

I am able to reproduce based on the following CodePen and 'down' arrow does not go to next line. Changing it to "New".

[Karl Dubost]

The markup in the codePen is

<div contenteditable="true">
  <p>
    The "down" key from here goes to this
    <span class="inline-block">inline-block</span>
    instead of going to ...
  </p>
  <p>... the next line</p>
</div>

with the style
.inline-block {
  display: inline-block;
  background-color: pink;
}

It seems that the arrow up and down in content editable navigates from block to block, if we remove the inline-block. The arrow navigation is going indeed to the next line. 

I don't know if keyboard navigation is specified in contenteditable markup. 
https://html.spec.whatwg.org/multipage/interaction.html#contenteditable

There was a similar issue of navigation for contenteditable stuff in Gecko
https://bugzilla.mozilla.org/show_bug.cgi?id=669026

I wonder if inline-block in the context of navigation line by line should be ignored. 

Is it part of this
https://searchfox.org/wubkat/rev/6c4c981002fe98d371b03ab862b589120661a63d/Source/WebCore/editing/FrameSelection.cpp#1631-1664

[Karl Dubost]

Ah probably more here. 
https://searchfox.org/wubkat/rev/6c4c981002fe98d371b03ab862b589120661a63d/Source/WebCore/editing/VisibleUnits.cpp#1013-1067

[Ahmad Saleem]

(In reply to Karl Dubost from comment #4)
> Ah probably more here. 
> https://searchfox.org/wubkat/rev/6c4c981002fe98d371b03ab862b589120661a63d/
> Source/WebCore/editing/VisibleUnits.cpp#1013-1067

I am already touching this piece in one of open PR to fix another keyboard navigation issue but I tested this CodePen and it is not fixed with that PR. Something still to figure out about this.

[Radar WebKit Bug Importer]

<rdar://problem/122587531>