Closed Bug 322903 Opened 16 years ago Closed 16 years ago

AccessibleText getTextAtOffset should not cause html pane scrolls


(Firefox :: Disability Access, defect)

Not set





(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)



(Keywords: access)


(6 files, 1 obsolete file)

Run the test case in Bug 317482.
Open this bug report in firefox and scroll the page down.
Press F11.
You'll see that the page scrolls to the top.
In nsAccessibleText::GetTextHelperCore
IntraLineMove / WordMove / CharacterMove causes selection change, so it scrolls
I'm attaching a simple HTML page and a simple standalone application that can easily reproduce this problem in text input areas.  This is a pretty severe bug because it causes really bad problems when people are typing in input areas (e.g.,  entering a google search or other information in an HTML form).
Attached file bug_322903.html
BTW, this is a showstopper for accessibility and Orca because it can result in very unpredictable/unusable behavior for the end user.  I'm not fully versed in the etiquette of assigning priorites and severities for Firefox, though, so I'll leave it up to you folks to decide the appropriate levels.
Attached patch patch (obsolete) — Splinter Review
Attachment #208947 - Flags: review?(aaronleventhal)
Comment on attachment 208947 [details] [diff] [review]

This is only a rough workaround for the specific testcase which Will posted.
It cannot work if there are mutiple textframes.

The ideal solution is not to touch caretOffset, selections, ranges, etc.

Performance is poor if we change selections frequently.
Attachment #208947 - Attachment is obsolete: true
Attachment #208947 - Flags: review?(aaronleventhal)
Severity: normal → blocker
Keywords: access, sec508
Use this testcase with the python script in Bug 317482 (,
you can find more unexpected scrolls.
This patch is for concept proof, doesn't need review.
(You can decrease firefox window size and test it with the 2 TextAreas testcase.)

I tried to restore scroll position, caret offset, and suppress rendering while it scrolls.
But unexpected results also can be observed.

1) When caret is at the beginning of an empty line, after pressing F11, it displays at the end of prev line. (if you type 'a' now, 'a' will be inserted to the 'empty' line but not the end of prev line, seems it's only a vision bug.)

2) If there is no selection in TextArea 1, and caret is in TextArea2. After pressing F11, TextArea 1 scrolls to the bottom.

3) ...
Comment on attachment 209561 [details]
Testcase of 2 TextAreas

oops, this test case caused dead loop with the python script.
But if I use empty textareas and copy&paste numbers and letters in, it can works.
(In reply to comment #10)
> (From update of attachment 209561 [details] [edit])
> oops, this test case caused dead loop with the python script.
> But if I use empty textareas and copy&paste numbers and letters in, it can
> works.
This issue is not caused by this patch.
Anyway, Firefox 1.5 doesn't have the problem.
Last testcase is blocked by another bug.
I tried Firefox below 1.0, also caused dead loop.
(I was wrong yesterday, Firefox 1.5 also has this issue.)
Blocks: fox2access
.stsixe llits melborp eht dna 1a0.2 noisrev ohcE noB htiw dekcehc tsuj I

I just want to make sure this bug has not been forgotten.  The above was written while running the python test app for this bug while running Bon Echo version 2.0a1.  I entered it in this order: "I just checked with Bon Echo version 2.0a1 and the problem still exists."  This problem is nasty in that it makes Firefox rather useless when it comes to entering any text from the keyboard.

If you need more info/help from me, please let me know.
I think we need to look at how nsSelection::MoveCaret works and take the useful pieces from that:

Things like:
GetFrameForNodeOffset(pos.mResultContent, pos.mContentOffset, tHint, &theFrame, &currentOffset);
theFrame->GetOffsets(frameStart, frameEnd);

This bug also makes Thunderbird nightlys unusable for a user of orca because one can not even fill out the fields in the new account wizzard.  When entering characters into the account fields characters are entered out of order.  
What about fix the reverse input first?
Attachment #221282 - Flags: review?(aaronleventhal)
Comment on attachment 221282 [details] [diff] [review]
patch (for reverse inputs only)

Yes, this is a good workaround until we get a better fix.
Attachment #221282 - Flags: superreview?(neil)
Attachment #221282 - Flags: review?(aaronleventhal)
Attachment #221282 - Flags: review+
Attachment #221282 - Flags: superreview?(neil) → superreview+
Attachment #221282 - Flags: approval-branch-1.8.1+
Of course, we have to wait until the tree reopens before checking in.
Checking in accessible/src/atk/nsAccessibleText.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v  <--  nsAccessibleText.cpp
new revision: 1.30; previous revision: 1.29

Checking in accessible/src/atk/nsAccessibleText.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v  <--  nsAccessibleText.cpp
new revision:; previous revision:
This has been checked in on branch and trunk, but we are leaving it open for a better fix.
No longer blocks: fox2access
Marking fixed because this did fix the bug for Firefox 2. However, this method isn't event implemented in trunk at the moment. The new implementation will occur in bug 342596 and must not have this problem.
Blocks: newatk
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.