Closed
Bug 312941
Opened 19 years ago
Closed 19 years ago
Caret move events not reported for XUL textboxes
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
References
Details
(Keywords: access, fixed1.8)
Attachments
(1 file)
8.44 KB,
patch
|
parente
:
review+
neil
:
superreview+
asa
:
approval1.8rc1+
|
Details | Diff | Splinter Review |
Steps: 1. Run MSAA Inspect 2. Enable viewing of caret move events 3. Move caret in address bar of Firefox What happens: Caret location change events are not reported but should be as they are for HTML. This would also help fix bug 244119 for Tablet PC support.
Assignee | ||
Comment 1•19 years ago
|
||
Attachment #200020 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #200020 -
Flags: review?(parente)
Comment 2•19 years ago
|
||
So, are there reasons why a) you don't special case nsIDOMXULTextBoxElement or b) you don't do all accessible events on the original target?
Assignee | ||
Comment 3•19 years ago
|
||
(In reply to comment #2) > a) you don't special case nsIDOMXULTextBoxElement What if a web author uses XBL to create a widget with a HTML input or textarea as anonymous content? This general rule will catch that. > b) you don't do all accessible events on the original target? Because the accessible itself is created for the XUL element. If we used the original target we would be handing back an nsHTMLInputAccessible for events instead of a nsXULTextBoxAccessible.
Updated•19 years ago
|
Attachment #200020 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attachment #200020 -
Flags: review?(parente) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #200020 -
Flags: approval1.8rc1?
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Attachment #200020 -
Flags: approval1.8rc1? → approval1.8rc1+
Comment 4•19 years ago
|
||
Unfortunately, while this fix does generate the proper caret location change events generated by mouse clicks, location changes originated from the keyboard, i.e. inserting text, still don't generate any events in the XUL textboxes. This can be verified with the MSAA Inspector. In reference to bug 244119 (Tablet PC support), this fix now allows the tablet extension to open the floating input panel when the XUL textboxes are clicked, but it automatically closes if the user types any keystroke on the onscreen keyboard and the textbox must be continually re-clicked after each keystroke to use the onscreen keyboard for input.
You need to log in
before you can comment on or make changes to this bug.
Description
•