371273 - at-spi events not generated when using Find toolbar

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

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.

Comment 1

[Joanmarie Diggs]

Attachment: at-spi event log as described in the report

This is the log resulting from pressing Control F, typing "sun", pressing Return four or five times, and finally pressing Escape.

Comment 2

[Aaron Leventhal]

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.

Comment 3

[Willie Walker]

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!

Comment 4

[Aaron Leventhal]

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.

Comment 5

[Aaron Leventhal]

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.

Comment 6

[Aaron Leventhal]

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.

Comment 8

[Aaron Leventhal]

See also bug 371279

Comment 9

[Aaron Leventhal]

This is a core issue because of comment 6

Comment 10

[Joanmarie Diggs]

(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.

Comment 11

[Aaron Leventhal]

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).

Comment 12

[Aaron Leventhal]

I should be able to post a patch this week for this.

Comment 13

[Aaron Leventhal]

Attachment: WIP. Mostly needs comments added. Refactors caret accessible.

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 14

[Aaron Leventhal]

Attachment: 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

Comment 15

[alexander :surkov (:asurkov)]

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.

Comment 16

[alexander :surkov (:asurkov)]

(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.

Comment 17

[alexander :surkov (:asurkov)]

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

Why aren't these events needed?

Comment 18

[alexander :surkov (:asurkov)]

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

Comment 19

[Aaron Leventhal]

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.