Open
Bug 1415504
Opened 7 years ago
Updated 2 years ago
Cursor can't be moved before image with background-image property in contenteditable div
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
NEW
People
(Reporter: al.govorkova, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [h2review-noted])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce: This issue is not reproduces if images has src, width and height. But if image is set via background-image and has paddings, it is reproduced. No issue in Chrome and IE. Related issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1414499 Steps: 1. Open http://jsfiddle.net/nLNCC/406/ 2. Set cursor to contentedirable div with image and 'test' text 3. Try to move the cursor before image Actual results: Cursor can't be moved before the image Expected results: Cursor is moved before the image
Updated•7 years ago
|
Component: Untriaged → Editor
Product: Firefox → Core
Updated•7 years ago
|
Priority: -- → P3
Updated•7 years ago
|
Blocks: editor-blink-compat
Comment 1•6 years ago
|
||
This bug might be dup of old bug, though. As far as I investigated, this is bug of selection in layout. nsIFrame::PeekOffset() checks result of PeekOffsetCharacter() first. The result won't be FOUND unless the current frame is a text frame: https://searchfox.org/mozilla-central/rev/b80994a43e5d92c2f79160ece176127eed85dcc9/layout/generic/nsFrame.cpp#8483 Then, if current frame is not text frame, it calls nsIFrame::GetFrameFromDirection(): https://searchfox.org/mozilla-central/rev/b80994a43e5d92c2f79160ece176127eed85dcc9/layout/generic/nsFrame.cpp#8489,8492 It checks if jumping line from start or end edge of current line and returns previous or next frame with nsFrameIterator simply. However, unless the next line is a text frame or a br frame, nsIFrame::PeekOffset() won't receive FOUND from PeekOffsetCharacter() nor PeekOffsetNoAmount(). So, it seems that we need to make a lot of inline frames return FOUND for making its start edge and end edge selectable. On the other hand, there is another issue. For example: <div contentedtiable><table><td>cell</td></table></div> in this case, Chrome allows users to move caret before or after the <table> from the cell. And of course, Chrome allows to move between 2 <table> elements too. So, perhaps, for fixing those issues completely, we need to make parent frame handle where caret can be in the loop of nsIFrame::PeekOffset(). If web apps want to allow this kind of editing, they need to implement caret moving by them with JS. I think that it's too hard and I don't think that they'll support Firefox even with such hack. So, I believe that this should be fixed even though required really risky changes.
Status: UNCONFIRMED → NEW
Component: Editor → Selection
Ever confirmed: true
Comment 2•6 years ago
|
||
Ah, but if the <img> has src attribute, user can move caret before the <img> even in this case.
Comment 3•6 years ago
|
||
In this case, the <img> created nsInlineFrame and it claims it's not selectable here: https://searchfox.org/mozilla-central/rev/b80994a43e5d92c2f79160ece176127eed85dcc9/layout/generic/nsFrame.cpp#9076-9079 the reason is, the frame has NS_FRAME_GENERATED_CONTENT state. Then, it tries to retrieve previous frames more but there is no frames anymore. Therefor, looks like that it does nothing.
Updated•4 years ago
|
Whiteboard: [h2review-noted]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•