Closed Bug 876540 Opened 11 years ago Closed 2 years ago

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


(Core :: Disability Access APIs, defect)

Not set





(Reporter: jdiggs, Unassigned)


(Blocks 2 open bugs)



(2 files)

Attached file 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
Attached file test script
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)
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.

I couldn't manage to reproduce this issue. Since the bug was logged 9 years ago, most likely isn't reproducible anymore for the reporter also.
Closing this bug as resolved: Worksforme.

Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.