322547 - Double clicking on list bullet selects word from previous item

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[dolphinling]

Double clicking on a list item will select the first word from that item and the first word from the previous item. Looks exactly like Bug 319675, but for lists.

Comment 1

[Uri Bernstein]

Testcase, please?

Comment 2

[dolphinling]

Testcase: 
data:text/html,<ul><li>text text<li>text text</ul>

added in URL.

It may be easier to reproduce if you increase text size, so it's easier to hit the actual item marker.

Comment 3

[Uri Bernstein]

This too was regressed by bug 316281.
However, the best way to fix this might be by fixing bug 200098.

Comment 4

[dolphinling]

This is somewhat superceded by bug 326758, though when that's fixed this will probably still be a problem.

Comment 5

[Uri Bernstein]

Changing the testcase URL to one which is not affected by bug 326758 (by removing the surrounding <ul></ul>).
The new URL does display the original problem, as of 2006-07-05 trunk.

Comment 6

[Uri Bernstein]

Some notes:

The reason that the fix for Bug 319675 (which is really just a workaround for bug 200098) doesn't work here is that nsFrame::PeekOffset (and therefore nsFrame::GetFrameFromDirection) is called on the LI frame, which is not a leaf frame. nsFrame::GetFrameFromDirection silently assumes that it's called on a leaf frame. If it isn't (as in this case), the test for detecting line-jumping fails.
Possible solution: at the beginning of GetFrameFromDirection, drill down to the first leaf. Alternatively, ASSERT that "this" is indeed a leaf frame, so that problems of this kind would become more obvious.

Now, why is the LI (non-leaf) frame passed to PeekOffset (by HandleMultiplePress, via PeekBackwardAndForward)? This happens because of the following chain of events:

GetContentOffsetsFromPoint() returns the LI's parent as the content, with an index to the LI itself. This is because GetSelectionClosestFrame returns the bullet frame(!), and the bullet frame's content is the LI node.
Had bullet frames been considered generated content (and marked with the NS_FRAME_GENERATED_CONTENT flag), GetSelectionClosestFrame would have returned the content of the LI instead, and all would be well.
Shouldn't bullet frames be considered generated content?

But even with GetContentOffsetsFromPoint() returning the offset to the LI, we might still have been OK, had nsFrameSelection::GetFrameForNodeOffset drilled down into a leaf frame - as it is apparently supposed to do. The code for the drilling down has been there forever, but it's ifdef'ed-out with the comment "XXX: We can't use this code yet because the hinting can cause us to attatch to the wrong line frame". I don't know if that comment is still true (or even exactly what it means). I do remember previous occasions where I was frustrated by that comment.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think making bullet frames NS_FRAME_GENERATED_CONTENT makes sense...

Comment 8

[Uri Bernstein]

This is fixed by the fix to bug 200098, although the issues in comment #6 should probably still be addressed somehow.