Open Bug 384452 Opened 13 years ago Updated 13 years ago

PeekOffset: whitespace in source causes incorrect HOME key behavior and other problems

Categories

(Core :: DOM: Selection, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: aaronlev, Assigned: ginnchen+exoracle)

References

Details

(Keywords: access)

Attachments

(1 file)

Attached file Testcase
1) Open the attached testcase
2) Turn on caret browsing (F7)
3) In the middle of the line "Broken" press the Home key
4) Notice that the caret jumps to the previous line

The only difference between "works" and "broken" is a space after the <br> in the broken case.

This also affects a11y -- causing bug 384101.
Blocks: 384101
Assignee: nobody → ginn.chen
Uri, will you have a chance to look at this?
I had a look at this.

What happens is that DrillDownToSelectionFrame() is called with the inline continuation frame (which is the first frame on the line). This frame has a single child, an empty text frame, which is not eligible to be returned as the "selection frame". Therefore, DrillDownToSelectionFrame() returns the continuation frame itself. PeekOffset() then fetches the content for that frame (that is, the <b> element), and, since we're looking for the line beginning, places the collapsed selection at the beginning of that content. Problem is, the content for the <b> element begins on the previous line.

This doesn't seem like it has a simple, safe, solution. I would think that  DrillDownToSelectionFrame() should not return its input frame in this case, since it's not really "selectable". But I'm not sure what it should return, and how this would affect other callers of this method. Sadly, I don't have much time to do further research.

Eli - perhaps you can help?
You need to log in before you can comment on or make changes to this bug.