The cursor can reach block elements inside contenteditable=false

NEW
Unassigned

Status

()

Core
Selection
P3
normal
3 years ago
7 months ago

People

(Reporter: david, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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).

Updated

3 years ago
Component: Untriaged → Editor
Product: Firefox → Core

Updated

3 years ago
Flags: needinfo?(ehsan)
Masayuki may have a good idea of what's up here.
Flags: needinfo?(ehsan) → needinfo?(masayuki)

Updated

7 months ago
Priority: -- → P3
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?
Status: UNCONFIRMED → NEW
Component: Editor → Selection
Ever confirmed: true
Flags: needinfo?(masayuki) → needinfo?(mats)
OS: Linux → All
Hardware: x86_64 → All

Comment 4

7 months ago
> 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?
Flags: needinfo?(mats)

Comment 5

7 months ago
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.
(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.
You need to log in before you can comment on or make changes to this bug.