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

NEW
Assigned to

Status

()

12 years ago
11 years ago

People

(Reporter: aaronlev, Assigned: ginnchen+exoracle)

Tracking

({access})

Trunk
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Created attachment 268377 [details]
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.
(Reporter)

Updated

12 years ago
Blocks: 384101
(Reporter)

Updated

12 years ago
Assignee: nobody → ginn.chen
(Reporter)

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.