If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Double clicking on list bullet selects word from previous item

RESOLVED FIXED

Status

()

Core
Selection
--
minor
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: dolphinling, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
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.
Testcase, please?
(Reporter)

Comment 2

12 years ago
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.
This too was regressed by bug 316281.
However, the best way to fix this might be by fixing bug 200098.
Blocks: 316281
Depends on: 200098
Keywords: regression
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 4

12 years ago
This is somewhat superceded by bug 326758, though when that's fixed this will probably still be a problem.
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.
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.
I think making bullet frames NS_FRAME_GENERATED_CONTENT makes sense...

Updated

11 years ago
Blocks: 344417
This is fixed by the fix to bug 200098, although the issues in comment #6 should probably still be addressed somehow.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

8 years ago
QA Contact: selection
You need to log in before you can comment on or make changes to this bug.