1415504 - Cursor can't be moved before image with background-image property in contenteditable div

Status: NEW

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

Description

[Alexandra Govorkova]

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

Comment 1

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

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.

Comment 2

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

Ah, but if the <img> has src attribute, user can move caret before the <img> even in this case.

Comment 3

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

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.