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

RESOLVED FIXED

Status

()

Firefox
Disability Access
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Evan Yan, Assigned: Aaron Leventhal)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

12 years ago
I think this was from bug 346833 which I reversed. This regression should be fixed in nightly builds.
(Reporter)

Comment 2

12 years ago
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.
(Reporter)

Comment 3

12 years ago
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.
(Reporter)

Comment 4

12 years ago
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.
(Reporter)

Comment 5

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

Comment 6

12 years ago
Evan, thanks. Do you have a strategy to patch it?
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

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

Updated

12 years ago
Depends on: 346833
(Assignee)

Updated

12 years ago
Blocks: 346833
No longer depends on: 346833
(Assignee)

Comment 10

12 years ago
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)
(Reporter)

Comment 11

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

Comment 12

12 years ago
Tim, please verify this fix when you have a chance.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

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