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

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

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

[Joanmarie Diggs]

Attachment: test script

Comment 2

[alexander :surkov (:asurkov)]

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(caretOffset);
dump(": '" + text + "', (" + startObj.value + ", " + endObj.value + ")\n");

Comment 3

[alexander :surkov (:asurkov)]

Here's an example:

<div>
<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.
</div>

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.

<div>
<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.
</div>

and thus there's no problem.

Not sure how to solve this bug, Ehsan ideas are welcome.

Comment 4

[(no longer active)]

I'm not sure if the inline frame containing "\n" is unexpected or not.  Ask roc?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.)

Comment 6

[alexander :surkov (:asurkov)]

Jonathan, this one is good to play with layout stuff.

Comment 7

[Hani Yacoub, Desktop QA]

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.