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

Assigned to



12 years ago
11 years ago


(Reporter: aaronlev, Assigned: ginnchen+exoracle)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
Created attachment 268377 [details]

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.


12 years ago
Blocks: 384101


12 years ago
Assignee: nobody → ginn.chen

Comment 1

11 years ago
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.