Closed
Bug 634240
Opened 13 years ago
Closed 13 years ago
No caret move events are fired for XUL textbox accessible
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
VERIFIED
FIXED
mozilla2.0b12
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: surkov, Assigned: surkov)
References
Details
(Keywords: access, regression, Whiteboard: [hardblocker][has patch])
Attachments
(1 file)
11.68 KB,
patch
|
davidb
:
review+
MarcoZ
:
feedback+
|
Details | Diff | Splinter Review |
regression from bug 615189
Assignee | ||
Comment 1•13 years ago
|
||
Attachment #512454 -
Flags: review?(bolterbugz)
Assignee | ||
Comment 2•13 years ago
|
||
Marco: example in UI is text fields in Boorkmarks dialog in the case if you like to verify it.
Comment 3•13 years ago
|
||
Comment on attachment 512454 [details] [diff] [review] patch r=me since this seems safe enough, but why doesn't the Accessible already have the correct node for this case? (nsIDOMXULTextBoxElement) I see you made the change for all cases of FireAccessibleFocusEvent, not just xul, so it might be good to get some general QA as not sure how worried that should make us? Tests look good. >+++ b/accessible/src/base/nsRootAccessible.cpp >@@ -512,16 +512,19 @@ nsRootAccessible::ProcessDOMEvent(nsIDOM >+ nsIContent* origTargetContet = origTargetNode->IsElement() ? >+ origTargetNode->AsElement() : nsnull; Nit: forgot the 'n' in origTargetContent (4 places).
Attachment #512454 -
Flags: review?(bolterbugz) → review+
Updated•13 years ago
|
blocking2.0: ? → final+
Whiteboard: [softblocker]
Updated•13 years ago
|
Whiteboard: [softblocker] → [hardblocker][has patch]
Updated•13 years ago
|
Attachment #512454 -
Flags: feedback?(marco.zehe)
Comment 4•13 years ago
|
||
Looks like Alexander has builds here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-501bb8e36187/
Assignee | ||
Comment 5•13 years ago
|
||
(In reply to comment #3) > Comment on attachment 512454 [details] [diff] [review] > patch > > r=me since this seems safe enough, but why doesn't the Accessible already have > the correct node for this case? (nsIDOMXULTextBoxElement) it has nsIDOMXULTextBoxElement but it's not correct node to register selection listener. XUL textbox is XUL wrapper on HTML input and all things are happen for HTML input while accessible is created for XUL textbox. > > >+ nsIContent* origTargetContet = origTargetNode->IsElement() ? > >+ origTargetNode->AsElement() : nsnull; > > Nit: forgot the 'n' in origTargetContent (4 places). thanks for the catch! (In reply to comment #4) > Looks like Alexander has builds here: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-501bb8e36187/ Yes :)
Assignee | ||
Comment 6•13 years ago
|
||
(In reply to comment #3) > I see you made the change for all cases of FireAccessibleFocusEvent, not just > xul, so it might be good to get some general QA as not sure how worried that > should make us? These changes don't make any sense since adding a selection controller for non text input controls don't make sense (it's handled by document). I just rollback part of bug 615189 for consistence.
Comment 7•13 years ago
|
||
Comment on attachment 512454 [details] [diff] [review] patch f=me. This bug definitely makes a difference and restores proper braille tracking with NVDA in the Bookmarks Library window and other places.
Attachment #512454 -
Flags: feedback?(marco.zehe) → feedback+
Assignee | ||
Comment 8•13 years ago
|
||
landed on 2.0 (fx4beta12) - http://hg.mozilla.org/mozilla-central/rev/2e288f06c648
Flags: in-testsuite+
Target Milestone: --- → mozilla2.0b12
Assignee | ||
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 9•13 years ago
|
||
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•