start firefox and open gnopernicus magnifier, in caret browsing mode, when using arrow key to move the caret, the magnificatioin window won't follow the caret. And so does inputting some text in a text field. this is a regression. reproduce: always
I think this was from bug 346833 which I reversed. This regression should be fixed in nightly builds.
the bug is still there. I tested on several build, try to find out the regression. however, because the code keep changing these days, the behaviors of different builds also keep changing. I think it would make more sense to fix this bug directly than to find out when the regression was introduced.
there are two problems: 1) no text-change or caret-move event fired when inputting/deleting in <textarea>. (we have the events fired for <input> textbox) 2) nsMaiInterfaceText.cpp:getCharacterExtentsCB is not called when inputting or caret browsing with magnifier open.
about the first one, nsHyperTextAccessible::DOMPointToOffset() failed at http://lxr.mozilla.org/seamonkey/source/accessible/src/html/nsHyperTextAccessible.cpp#480 It turned out nsHyperTextAcc object's mAccChildCount is zero, and mFirstChild is null. so NextChild() will failed and it never goes into the while loop.
the regression of no text-change event fired is between 2006-08-17 and 2006-08-18 nightly build. when CacheChildren() for nsHyperTextAcc object, nsAccessibleTreeWalker::GetFirstChild() will fail, because nsAccessibilityService::GetAccessible() can't get the accessible object. I also can't get the text in <textarea> by at-poke.
Evan, thanks. Do you have a strategy to patch it?
the regression of no text-change event fired is cause by this check-in: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/accessible/src/base&command=DIFF_FRAMESET&file=nsAccessibleTreeWalker.cpp&rev1=1.18&rev2=1.19&root=/cvsroot we need the judgement of mState.frame->GetContent()->IsNativeAnonymous(). when CacheChildren() for nsHyperTextAcc object, nsAccessibleTreeWalker::GetFirstChild() will be recursively called to get the child, which calls nsAccessibleTreeWalker::UpdateFrame() everytime. In nsAccessibleTreeWalker::UpdateFrame(), mState.frame first is nsTextControlFrame, then nsHTMLScrollFrame, then nsScrollbarFrame. mState.frame->GetContent()->IsNativeAnonymous() will return false for nsScrollbarFrame. reopened bug 346833 for this.
It turns out that bug 346833 also regressed bug 352150. For <span>x<br>y</span>, no accessible object is created for "y"
Are there currently any problems other than for <textarea>? I am understanding the textarea problem, and am trying to fix it and keep the fix for bug 346833.
Created attachment 238627 [details] [diff] [review] Implement a smart CacheChildren() for editor fields, in order to create child text accessibles. Not necessary for XUL textbox which already walks anon content to get it
Assignee: Evan.Yan → aaronleventhal
Status: NEW → ASSIGNED
Attachment #238627 - Flags: review?(Evan.Yan)
Comment on attachment 238627 [details] [diff] [review] Implement a smart CacheChildren() for editor fields, in order to create child text accessibles. Not necessary for XUL textbox which already walks anon content to get it the patch did fix the first problem mentioned in comment #3. We didn't set walker.mState.frame=GetFrame() in nsHTMLTextFieldAccessible::CacheChildren(), and that's the key we can get the accessible object. Is it reasonable to leave mState.frame null here? My lack of layout knowledge prevent me from understand this impl totally. do we need a sr here?
Attachment #238627 - Flags: review?(Evan.Yan) → review+
Tim, please verify this fix when you have a chance.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
rename the subject to what this bug actuallly solved. filed bug 353293 for the other issue mentioned in comment #3.
Summary: magnifier doesn't follow the inputting or caret browsing → no text-change or caret-move event fired when inputting/deleting in <textarea>
You need to log in before you can comment on or make changes to this bug.