1155031 - The cursor can reach block elements inside contenteditable=false

Status: NEW

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

Description

[david]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/41.0.2272.76 Chrome/41.0.2272.76 Safari/537.36

Steps to reproduce:

Goto http://jsfiddle.net/jnwtv1r0/1/
Cursor left/right as directed 


Actual results:

The cursor can enter each block element inside a contenteditable=false div.


Expected results:

The cursor should skip over the entire contenteditable=false div in a single bound.

Comment 1

[david]

As the above test case can also show, the up/down cursoring behaviour is different: there is a single cursor position visually inside the contenteditable=false div at the end of the first inner block (which is wrong). Its DOM position is reported as beside the contenteditable=false div (which is more reasonable).

Comment 2

[Andrew Overholt [:overholt]]

Masayuki may have a good idea of what's up here.

Comment 3

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

This must be a Selection's bug.

Elements of contenteditable="false" has "-moz-user-select: all". Therefore, when nsIFrame::PeekOffset() looks for next frame with nsIFrame::GetFrameFromDirection(), it considers the non-editable frame is next frame to put the caret.
https://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/layout/generic/nsFrame.cpp#7953,7969,7994
https://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/layout/generic/nsFrame.cpp#8454,8473,8535,8577,8581,8589

Perhaps, if focused node is an editable node, the methods should look for next/previous editable node instead of only checking "user-select" value.

What do you think, mats?

Comment 4

[Mats Palmgren (inactive)]

> Elements of contenteditable="false" has "-moz-user-select: all".

Fwiw, that seems slightly odd to me.  It means it's impossible to select
part of the text inside that element, to do a copy-paste for example.

> Perhaps, if focused node is an editable node, the methods should look for next/previous editable node instead of only checking "user-select" value.

It depends on how we want the caret to behave inside editable elements.
If we see it only as an "editing caret" then some selection operations
inside it will probably behave oddly.

But sure, looking for the next editable node is probably OK here.

I would probably avoid changing PeekOffset etc directly though,
because they've been extremely prone to regressions historically.
I wonder if we could just call it again, with eSelectCharacter,
until we get something editable?

Comment 5

[Mats Palmgren (inactive)]

A problem we probably should address too in relation to this:
nothing happens when typing backspace with the caret at the start of
the line after the non-editable block.  I'd expect the entire
non-editable block to be deleted by that.

Comment 6

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

(In reply to Mats Palmgren (:mats) from comment #5)
> A problem we probably should address too in relation to this:
> nothing happens when typing backspace with the caret at the start of
> the line after the non-editable block.  I'd expect the entire
> non-editable block to be deleted by that.

Yeah, I know that backspace key also doesn't remove invisible elements before that. For example:

<p>foo</p>
<input type="hidden">
<p>[]bar</p>

When I investigated this last Friday, I believe that we need to rewrite backspace key handling in HTMLEditRules.

Comment 7

[Tyler Kennedy]

I imagine this issue can be closed, the described behaviour has worked for quite some time (left/right and up/down). The included sample works as expected.

Comment 8

[david]

I agree, it works properly for me in Firefox 69.