14.18 KB, text/x-python
76 bytes, text/html
259 bytes, text/html
3.99 KB, patch
|Details | Diff | Splinter Review|
521 bytes, text/html
1.30 KB, patch
|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
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).
Created attachment 208853 [details] Standalone demonstration of bug - use accompanying 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.
Created attachment 208947 [details] [diff] [review] patch
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.
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.
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) ...
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] ) > 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.
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.)
.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: 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);
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.
Created attachment 221282 [details] [diff] [review] patch (for reverse inputs only) What about fix the reverse input first?
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) → superreview+
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 done Checking in accessible/src/atk/nsAccessibleText.cpp; /cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v <-- nsAccessibleText.cpp new revision: 18.104.22.168; previous revision: 22.214.171.124 done
This has been checked in on branch and trunk, but we are leaving it open for a better fix.
No longer blocks: 333488
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.
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.