Object delivered to Accessibility event listener, "(redundant object)", is no help

RESOLVED INVALID

Status

()

Firefox
Disability Access
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: Samuel B. Quiring, Unassigned)

Tracking

({access})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2009012320 Minefield/3.0.5

Why can't Minefield (and Firefox for that matter) deliver the actual object instead of "(redundant object)" to AT-SPI event listeners?

My accessibility app sets up the listener with this code:

 buttonPressListener = SPI_createAccessibleEventListener(buttonPressHandler, 0);
 SPI_registerGlobalEventListener(buttonPressListener, "Gtk:GtkWidget:button-press-event");

Here's the beginning of the handler:

void buttonPressHandler (const AccessibleEvent *event, void *user_data)
{
    char buf[1024];
    myLog("ev %s (x: %d, y: %d) %s", event->type, current_x, current_y,
        accessibleAsString(event->source, buf));

accessibleAsString tries to print "role(name)" where:
  roll = Accessible_getRoleName(event->source);
  name = Accessible_getName(event->source);

 It prints "(redundant object)", so role == "".

The Accessibility object, event->source, has no parent.  What gives?  Why can't Minefield (and Firefox) deliver an Accessible *pointer to the actual object under the mouse?


Reproducible: Always

Steps to Reproduce:
1.  In your AT app, set up a listener as described above
2.  run the AT-SPI event loop
3.  click on anything in Minefield (I chose the "Help" menu item in the main menu).


Actual Results:  
The event->source delivered to the listener is (redundant object).

Expected Results:  
An Accessible *pointer to the object in the AT-SPI tree.

See Expected Results.
(Reporter)

Comment 1

9 years ago
"redundant object" is the role name, *not* the name.  Sorry.
Thanks for the report. I wonder if this is related to bug 422744?
(Reporter)

Comment 3

9 years ago
I do not think so.

It is possible that I am listening for the wrong event.  For the user clicking on a menu item, I am expecting that my event handler for this event is correct:

Gtk:GtkWidget:button-press-event

As I said, I do get this event, but the object delivered to the handler is "redundant object" and (as I mentioned in bug 480347) there's no way that I can tell to figure out the real menu item that was clicked.

In comment #5 of bug 422744, Marco Zehe refers to events "menustart" and "popupstart".  Are these AT-SPI events?  These events are not listed in the "Supported AT-SPI Events" in (https://developer.mozilla.org/en/Accessibility%2f%2fAT-SPI_Support#Supported_AT-SPI_Events).
Keywords: access
(In reply to comment #3)
> In comment #5 of bug 422744, Marco Zehe refers to events "menustart" and
> "popupstart".  Are these AT-SPI events?  These events are not listed in the
> "Supported AT-SPI Events" in
> (https://developer.mozilla.org/en/Accessibility%2f%2fAT-SPI_Support#Supported_AT-SPI_Events).

Right, there is no such event for at-spi. In this case, for our internal event EVENT_MENUPOPUP_START, we fire a focus event, and two state change events (visible and showing = true).

Comment 5

9 years ago
Most widgets you saw in Firefox window are not real gtk widget, they just look like a native gtk widget.
So you can't get the information from "Gtk:GtkWidget:button-press-event" event.

You should listen to AT-SPI events. e.g. "focus".

I guess if you listen to "Gtk:GtkWidget:button-press-event", libgail with give the a11y object for the native GTK window. We intent to make its role as "redundant object", so that it can be ignored for a11y events.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

9 years ago
I do listen for focus, but only to log.  When the user clicks on the Help menu and the "Help Menu" comes up, he then will typically slide his mouse over each of the menu items until he gets to the bottom one, "About Mozilla Firefox".  I get a focus event for each menu item as the mouse glides over it.  So focus does not deliver "the user clicked on this menu item".

Of all the events I'm listening for here's what comes in when the user clicks on the menu item (with seconds.millisecons to the left):

 1. focus: About Mozilla Firefox (menu item) -- mouse arrives
 2. Mouse(Device) key 1 pressed
 3. Gtk:GtkWidget:button-press-event: redundant object
 4. mouse:button:1p
 5. Mouse(Device) key 1 released
 6. mouse:button:1r
 7. focus: Welcome To firefox - Mozilla Firefox (Frame)
 8. window:deactivate: Welcome to Firefox - Mozilla Firefox(frame)
 9. window:activate: About Mozilla Firefox(dialog)
10. focus: about:blank(panel)
...

My goal is to capture "the user clicked on a specific menu item".  What would you recommend to do this for FF and Minefield?  Is there an AT-SPI event for which I should be listening that I'm not?

I can try special case handling in Gtk:GtkWidget:button-press-event.  If the delivered object is "redundant object", and the app containing the most-recent focus is FF or Minefield, then use the most recent focus object.

I have some experience with one event handler remembering an object and another one using it.  Remembered focus objects can disappear. For example, if the user clicks the "ok" button to dismiss a dialog, the button is the last object to have the focus.  While the mouse click is being delivered, the system is also trying to tear down the dialog and the "ok" button with it.  Sometimes the "ok" button is still there when the mouse click is delivered.  Sometimes not.  The situation is much worse if you try to be super-pure: You should wait for the "release" mouse click -- the user can press the mouse and then slide the mouse off the object, in which case nothing happens when he releases the button.  But if he kept the mouse on the "ok" button then waiting for the release event means the system has had more time to tear down the dialog.
You need to log in before you can comment on or make changes to this bug.