Closed
Bug 322903
Opened 19 years ago
Closed 18 years ago
AccessibleText getTextAtOffset should not cause html pane scrolls
Categories
(Firefox :: Disability Access, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)
References
Details
(Keywords: access)
Attachments
(6 files, 1 obsolete file)
14.18 KB,
text/x-python
|
Details | |
76 bytes,
text/html
|
Details | |
259 bytes,
text/html
|
Details | |
3.99 KB,
patch
|
Details | Diff | Splinter Review | |
521 bytes,
text/html
|
Details | |
1.30 KB,
patch
|
aaronlev
:
review+
neil
:
superreview+
aaronlev
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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
Comment 2•18 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•18 years ago
|
||
Comment 4•18 years ago
|
||
Comment 5•18 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.
Comment 6•18 years ago
|
||
Attachment #208947 -
Flags: review?(aaronleventhal)
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•18 years ago
|
Use this testcase with the python script in Bug 317482 (https://bugzilla.mozilla.org/attachment.cgi?id=203991), 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) ...
Assignee | ||
Comment 10•18 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•18 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•18 years ago
|
||
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•18 years ago
|
Blocks: fox2access
Comment 13•18 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•18 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, ¤tOffset); theFrame->GetOffsets(frameStart, frameEnd);
Comment 15•18 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•18 years ago
|
||
What about fix the reverse input first?
Attachment #221282 -
Flags: review?(aaronleventhal)
Comment 17•18 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•18 years ago
|
Attachment #221282 -
Flags: superreview?(neil) → superreview+
Updated•18 years ago
|
Attachment #221282 -
Flags: approval-branch-1.8.1+
Comment 18•18 years ago
|
||
Of course, we have to wait until the tree reopens before checking in.
Assignee | ||
Comment 19•18 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•18 years ago
|
||
This has been checked in on branch and trunk, but we are leaving it open for a better fix.
No longer blocks: fox2access
Comment 21•18 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.
Comment 22•5 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•