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

Status: NEW

(Core :: DOM: Selection, defect)

Description

[Aaron Leventhal]

Attachment: 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.

Comment 1

[Aaron Leventhal]

Uri, will you have a chance to look at this?

Comment 2

[Uri Bernstein]

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?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.