AccessibleText getTextAtOffset should not cause html pane scrolls

RESOLVED FIXED

Status

()

--
blocker
RESOLVED FIXED
13 years ago
12 years ago

People

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

Tracking

({access, sec508})

Trunk
x86
Linux
access, sec508
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Assignee)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
In nsAccessibleText::GetTextHelperCore
IntraLineMove / WordMove / CharacterMove causes selection change, so it scrolls

Comment 2

13 years ago
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).

Comment 3

13 years ago
Created attachment 208853 [details]
Standalone demonstration of bug - use accompanying bug_322903.html

Comment 4

13 years ago
Created attachment 208854 [details]
bug_322903.html

Comment 5

13 years ago
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.
Created attachment 208947 [details] [diff] [review]
patch
Attachment #208947 - Flags: review?(aaronleventhal)
(Assignee)

Comment 7

13 years ago
Comment on attachment 208947 [details] [diff] [review]
patch

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)

Updated

13 years ago
Severity: normal → blocker
Keywords: access, sec508
(Assignee)

Comment 8

13 years ago
Created attachment 209561 [details]
Testcase of 2 TextAreas

Use this testcase with the python script in Bug 317482 (https://bugzilla.mozilla.org/attachment.cgi?id=203991),
you can find more unexpected scrolls.
(Assignee)

Comment 9

13 years ago
Created attachment 209562 [details] [diff] [review]
workaround v0.2 (concept proof only)

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

Comment 10

13 years ago
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.
(Assignee)

Comment 11

13 years ago
(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.
(Assignee)

Comment 12

13 years ago
Created attachment 209666 [details]
2 textareas testcase (workaround the dead loop)

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

Updated

13 years ago
Blocks: 333488

Comment 13

13 years ago
.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.

Comment 14

13 years ago
I think we need to look at how nsSelection::MoveCaret works and take the useful pieces from that:
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#1309

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




Comment 15

13 years ago
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.  
(Assignee)

Comment 16

12 years ago
Created attachment 221282 [details] [diff] [review]
patch (for reverse inputs only)

What about fix the reverse input first?
Attachment #221282 - Flags: review?(aaronleventhal)

Comment 17

12 years ago
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+

Updated

12 years ago
Attachment #221282 - Flags: superreview?(neil) → superreview+

Updated

12 years ago
Attachment #221282 - Flags: approval-branch-1.8.1+

Comment 18

12 years ago
Of course, we have to wait until the tree reopens before checking in.
(Assignee)

Comment 19

12 years ago
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
done

Checking in accessible/src/atk/nsAccessibleText.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v  <--  nsAccessibleText.cpp
new revision: 1.24.8.2; previous revision: 1.24.8.1
done

Comment 20

12 years ago
This has been checked in on branch and trunk, but we are leaving it open for a better fix.
No longer blocks: 333488

Comment 21

12 years ago
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: 333492
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.