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.
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).
Masayuki may have a good idea of what's up here.
Flags: needinfo?(ehsan) → needinfo?(masayuki)
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
> 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?
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.