Last Comment Bug 312941 - Caret move events not reported for XUL textboxes
: Caret move events not reported for XUL textboxes
Status: RESOLVED FIXED
: access, fixed1.8, sec508
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Aaron Leventhal
:
Mentors:
Depends on:
Blocks: 244119
  Show dependency treegraph
 
Reported: 2005-10-18 17:49 PDT by Aaron Leventhal
Modified: 2005-10-20 17:27 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Attach selection listener to original target for focus events, which is where the focus really is. For XUL textboxes this allows us to listen to selection in the HTML input for it. (8.44 KB, patch)
2005-10-18 17:53 PDT, Aaron Leventhal
parente: review+
neil: superreview+
asa: approval1.8rc1+
Details | Diff | Review

Description Aaron Leventhal 2005-10-18 17:49:55 PDT
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.
Comment 1 Aaron Leventhal 2005-10-18 17:53:48 PDT
Created attachment 200020 [details] [diff] [review]
Attach selection listener to original target for focus events, which is where the focus really is. For XUL textboxes this allows us to listen to selection in the HTML input for it.
Comment 2 neil@parkwaycc.co.uk 2005-10-19 05:24:21 PDT
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?
Comment 3 Aaron Leventhal 2005-10-19 06:19:06 PDT
(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.
Comment 4 Ian Weiner 2005-10-20 17:27:31 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.