Closed Bug 382021 Opened 17 years ago Closed 8 years ago

Caret-moved event not being triggered on entry during load

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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.
Do you also look for focus: events?  I think these might be the better event to look for.
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.
If the caret doesn't move, are there still instances where you expect a caret moved event?
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.
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!
I did not realize we were inconsistent with GAIL.

Peter, should I remove caret event when there is already a focus event?
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?
Talked to Will -- this is lower priority since a focus event is received.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Depends on: 566103
I marked bug 566103 as dependent for this one by mistake.
No longer depends on: 566103
Fernando, could you please check if this is issue still?
It is. We are not firing object:text-caret-moved when the page set the focus to the entry
We neither fire it when we do Activate() over the entry accessible.
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
Fernando, would you like to take it?
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.