Closed
Bug 382021
Opened 18 years ago
Closed 8 years ago
Caret-moved event not being triggered on entry during load
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: scott, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [auto-closed:inactivity])
Google's homepage uses Javascript to set the caret in the entry box when the page first loads. However, I am not receiving a caret-moved event. On the other hand, tabbing to the box produces the caret-moved event I am looking for.
Comment 1•18 years ago
|
||
Do you also look for focus: events? I think these might be the better event to look for.
Reporter | ||
Comment 2•18 years ago
|
||
Yes, we also look at focus events and expect them too. Caret events, on the other hand, trigger announcements concerned with selected text (or blank). We have many different types of announcements keyed to certain event types. It is essential that all event types are received and are correct.
Comment 3•18 years ago
|
||
If the caret doesn't move, are there still instances where you expect a caret moved event?
Reporter | ||
Comment 4•18 years ago
|
||
Not that I am aware of. I will pose this question to Peter tomorrow.
We're just looking for consistency, one way or the other. If manually giving focus to the empty search entry box fires focus: then object:caret-moved, I would expect programmatic focus to the same search box to fire the same sequence of events. Alternatively, if we want to consider no caret movement event the correct behavior (and keep it consistent with gail), then I would expect only the focus: event for both programmatic and manual cases.
Comment 6•18 years ago
|
||
Agreed -- consistency in the implementation is important, and I'd also expect consistency across implementations. Unless it seems blatantly wrong, I'd always opt for being consistent with GAIL. Thanks!
Comment 7•18 years ago
|
||
I did not realize we were inconsistent with GAIL. Peter, should I remove caret event when there is already a focus event?
Comment 8•18 years ago
|
||
I'm confused about what we should do for this bug at this point. Will, any advice? To me it seems like we should be firing a caret move event for it, since the caret has moved from the top of the document into the search box. Or, what is it that GAIL does differently that we should be consistent with and aren't?
Comment 10•15 years ago
|
||
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Comment 11•15 years ago
|
||
I marked bug 566103 as dependent for this one by mistake.
No longer depends on: 566103
Comment 13•14 years ago
|
||
It is. We are not firing object:text-caret-moved when the page set the focus to the entry
Comment 15•14 years ago
|
||
Ok, we ignore them if the document is not loaded - http://mxr.mozilla.org/mozilla-central/source/accessible/src/base/nsCaretAccessible.cpp#233. Iirc previously we had a problems because we fired them too much, we should check if that's valid. I suspect it's not an issue anymore. Let's figure it out for fx5.
Blocks: a11ynext
Comment 17•8 years ago
|
||
AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [auto-closed:inactivity]
You need to log in
before you can comment on or make changes to this bug.
Description
•