349860 - no text-change or caret-move event fired when inputting/deleting in <textarea>

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Evan Yan]

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

Comment 1

[Aaron Leventhal]

I think this was from bug 346833 which I reversed. This regression should be fixed in nightly builds.

Comment 2

[Evan Yan]

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.

Comment 3

[Evan Yan]

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.

Comment 4

[Evan Yan]

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.

Comment 5

[Evan Yan]

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.

Comment 6

[Aaron Leventhal]

Evan, thanks. Do you have a strategy to patch it?

Comment 7

[Evan Yan]

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.

Comment 8

[Aaron Leventhal]

It turns out that bug 346833 also regressed bug 352150.
For <span>x<br>y</span>, no accessible object is created for "y"

Comment 9

[Aaron Leventhal]

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.

Comment 10

[Aaron Leventhal]

Attachment: 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

Comment 11

[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?

Comment 12

[Aaron Leventhal]

Tim, please verify this fix when you have a chance.

Comment 13

[Evan Yan]

rename the subject to what this bug actuallly solved. filed bug 353293 for the other issue mentioned in comment #3.