Closed Bug 371273 Opened 14 years ago Closed 14 years ago

at-spi events not generated when using Find toolbar

Categories

(Core :: Disability Access APIs, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiggs, Assigned: aaronlev)

References

(Blocks 3 open bugs)

Details

(Keywords: access)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre

When the user activates the Find toolbar and begins typing text, matching text within the document frame becomes highlighted, the frame scrolling if necessary to display the matching text, etc.  Pressing Return to find subsequent matches also causes this to occur.

Using at-poke to log events while performing a find reveals that events are generated when the Find toolbar gains focus, when text is inserted into the Find entry, and when the document frame regains focus as a result of pressing Escape from within the Find toolbar.  It seems that events are NOT being generated for the text that matches the query.  at-poke event log to be attached.

Reproducible: Always

Steps to Reproduce:
1. Launch at-poke and enable event logging
2. Navigate to a web page
3. Press Control F to move focus to the Find toolbar, type some text, and press Return a few times to find subsequent matches.
Actual Results:  
Events are not being generated with respect to the matching text in the document frame.

Expected Results:  
Events would be generated with respect to the matching text in the document frame.
This is the log resulting from pressing Control F, typing "sun", pressing Return four or five times, and finally pressing Escape.
Keywords: access
What events are you expecting? I just want to make sure our expectations are the same.

I would expect a selection move event in the document.
Blocks: ia2, atk
Some sort of object:text-selection-changed event would be nice.  I'm not sure I've seen a selection move event - does such a thing exist?  In addition, when the user presses escape to get out of the Find area, it would be very useful to get a caret moved event telling us where the caret ended up.  Thanks!
Sorry, I should have said object:text-selection-change.

We call it a selection move internally, and it gets mapped to the appropriate event on each platform.
We probably don't fire it because focus is currently in the find bar, and we probably suppress the selection and caret events when focus isn't somewhere in that object.
Blocks: texta11y
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: orca
That's what it is. We only fire selection events for the focused element. Here's where we attach a new internal selection listener when the focus changes.
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsRootAccessible.cpp#448

I'm not sure what the correct design change would be.
Duplicate of this bug: 337557
See also bug 371279
Assignee: nobody → aaronleventhal
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
This is a core issue because of comment 6
Blocks: lsr
No longer blocks: lsr
Blocks: lsr
(In reply to comment #6)
> I'm not sure what the correct design change would be.

What about caret-moved events?

Now that text.getNSelections() returns a non-zero value when text is selected in the document frame, we can provide much better access when the user returns to the document frame from the Find tool bar.  (Thanks!)

The kicker is that without a caret-moved event, we still think the caret is wherever it was before we did the search.  If the selected text is within that object, we can immediately get its start and end offset; if it's not, we have to search object by object until we find the object that contains the selection.

If Firefox could issue caret-moved events for the document frame even when it didn't have focus, not only would we not have to search around for the selection post-search, I would think that we should be able to provide access to the changing contents of the screen during the search.
Right, we fire caret and selection events in the same place. It's clear we need to do that.

The design part I'm not sure about yet is more
1) An internal coding question for the nsCaretAccesible ownership model
2) Whether to make Firefox fire caret and selection events for everything now, or keep some limits on it. For example, should we fire only for the currently visible tab (seems reasonable).

I should be able to post a patch this week for this.
This might also fix bug 244119, because it fixes an issue with caret move events when the user types. The caret is temporarily invisible when typing, and still is in the NotifySelectionChanged() callback. This is fixed by delaying the firing of the MSAA location_change event and the calculation of the caret bounds.
Comment on attachment 263597 [details] [diff] [review]
Listen to selection for the currently focused control, as well as on all documents. More comments in nsIAccessibleCaret.idl and nsCaretAccessible.h. Moves old MSAA caret event into MSAA nsAccWrap


>+  nsCOMPtr<nsISelectionController> selCon = do_QueryInterface(doc->GetShellAt(0));
>+  NS_ENSURE_TRUE(selCon, NS_ERROR_FAILURE);

You should use getPrimaryShell(), right?

>+  if (eventType == nsIAccessibleEvent::EVENT_TEXT_CARET_MOVED) {
>+    // Fire additional old-style MSAA caret events as well as the IA2 event
>+    nsRefPtr<nsRootAccessible> rootAccessible = GetRootAccessible();
>+    if (rootAccessible) {
>+      nsCOMPtr<nsIAccessible> caretAccessible;
>+      void* handle = nsnull;
>+      rootAccessible->GetWindowHandle(&handle);
>+      NotifyWinEvent(EVENT_OBJECT_LOCATIONCHANGE, (HWND)handle, OBJID_CARET, CHILDID_SELF);
>     }

IA2_EVENT_TEXT_CARET_MOVED won't be fired, right?

More comments a bit later.
(In reply to comment #15)
> (From update of attachment 263597 [details] [diff] [review])

> IA2_EVENT_TEXT_CARET_MOVED won't be fired, right?

Ah, it looks it will.
#ifdef XP_WIN
    mRootAccessible->FireToolkitEvent(mVisible? nsIAccessibleEvent::EVENT_SHOW: 
                                      nsIAccessibleEvent::EVENT_HIDE, this, nsnull);
#endif

Why aren't these events needed?
Comment on attachment 263597 [details] [diff] [review]
Listen to selection for the currently focused control, as well as on all documents. More comments in nsIAccessibleCaret.idl and nsCaretAccessible.h. Moves old MSAA caret event into MSAA nsAccWrap

rest looks ok
Attachment #263597 - Flags: review?(surkov.alexander) → review+
I didn't add EVENT_SHOW and EVENT_HIDE for caret because it's not clear those are being used for anyone. With the new system I couldn't come up with a quick and easy way to support them. You can get the same info by checking the state of the caret when its location changes.

I could think of a few ways of doing it. But first I would like to see if anyone is missing it. I will ask the Tablet PC people. They're the only ones I believe are actually using the MSAA caret. We would have heard if there are others because our MSAA caret was broken when the user types in characters. Only the Tablet PC folks complained about that.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Duplicate of this bug: 335668
You need to log in before you can comment on or make changes to this bug.