get_text_at_offset() sometimes returns the first line of text when given the final character's offset




6 years ago
5 years ago


(Reporter: jdiggs, Unassigned)


(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
Created attachment 754610 [details]
test case

Steps to reproduce:
1. Open the attached test case
2. Launch the attached test script in a terminal
3. Arrow from the top of the document to the bottom

Expected results: the correct line text and offsets would be reported.

Actual results: When you arrow to the blank line between the first block of text and the second, the following appears in the terminal:

line: <Orca is looping in this text > start: 0 offset: 80 end: 29

Comment 1

6 years ago
Created attachment 754611 [details]
test script
Blocks: 613857
DOMi script:

var caretOffset = event.QueryInterface(Ci.nsIAccessibleCaretMoveEvent).caretOffset;
var startObj = {}, endObj = {};
var text = target.getTextAtOffset(caretOffset, Ci.nsIAccessibleText.BOUNDARY_LINE_START, startObj, endObj);
dump(": '" + text + "', (" + startObj.value + ", " + endObj.value + ")\n");
Here's an example:

<strong>Orca is looping in this text because the line at the final offset is incorrect.<br />
<br />Get rid of the div and the bug goes away.

DIV has 4 lines
1st line InlineFrame containing nsTextFrame "Orca is looping in this text because the line
2nd line (InlineFrame containing nsTextFrame "at the final offset is incorrect."
3d line (InlineFrame having nsTextFrame presumably "\n") and BRFrame
4th line (InlineFrame): Get rid of the div and the bug goes away.

PeekOffset on BRFrame for eSelectBeginLine returns 3d InlineFrame, content is DIV, contentOffset is 1, attachForward is true. That makes to think us that we are at beginning of STRONG element (while we are at the end of it).

I don't see a reason why layout creates 3d InlineFrame. If </strong> goes right after <br /> then there's no InlineFrame, i.e.

<strong>Orca is looping in this text because the line at the final offset is incorrect.<br /></strong>
<br />Get rid of the div and the bug goes away.

and thus there's no problem.

Not sure how to solve this bug, Ehsan ideas are welcome.
Severity: normal → major
Flags: needinfo?(ehsan)

Comment 4

6 years ago
I'm not sure if the inline frame containing "\n" is unexpected or not.  Ask roc?
Flags: needinfo?(ehsan) → needinfo?(roc)
It's expected. Every character of a text node ends up in a text frame. If the node is inside an inline element, the text frame will be inside an inline frame.

(OK, there's some optimizations we do in the absence of inline frames that skip creating text frames for whitespace-only text nodes at the start or end of a block, but those are just optimizations and nothing should rely on or be affected by them.)
Flags: needinfo?(roc)
Jonathan, this one is good to play with layout stuff.
You need to log in before you can comment on or make changes to this bug.