GNOME Bugzilla – Bug 137401
default accessible action on the back button drop down fails
Last modified: 2004-12-22 21:47:04 UTC
using GOK from CVS HEAD Mar 15 -launch nautilus -attempt to UI Grab the 'drop down' arrow beside the 'back' toolbar button .the button is pressed but the context menu does not pop up. .doing so with a mouse brings up the context menu. .one has to UI Grab the button again just to deselect it.
Sounds like a nautilus bug to me.
I tried it via at-poke and got the same behaviour -- and then at-poke crashed and hung the session. I'm moving to nautilus - please correct me if I'm wrong...
With at-poke, if I choose the press action I get the menu displayed. This may be an inconsistency with other buttons. Transferred back to gok for further evaluation.
It is an interesting case. Using neither gok nor at-poke, and simple pressing on the button works, but clicking on the button also works. Seems to me the click action should be consistent with that but is not. So I think in this should be fixed in nautilus, however it has exposed (or added evidence of) a weakness for cases where a refined action is desired... Padraig, do you agree this case is inconsistent and should be fixed in nautilus?
I am transferring this bug back to nautilus. I will append a patch which causes the button to be activated when it is clicked. I think that makes it consistent with other buttons.
Created attachment 25973 [details] [review] Proposed patch
This patch is incorrect. The 'drop down' arrow displays the menu when the button is pressed. It behaves in a similar way to a menu. The behavior is similar to that of the 'drop down' arrows in mozilla. Trasnferring back to
I see two questions: 1) What actions should be implemented by these toggle buttons which contain a DownArrow and what role should they have? 2) Can we recognize these buttons in gail or do we need nautilus to implement them as a specialization of GtkToggleButton with an accessible implementation?
Padraig, just to clarify -- doesn't the 'drop down' arrow (at least in nautilus) display the menu when the button is pressed OR clicked? You questions are good ones. Is there also a third question: 3. Should the down arrow be treated as a separate widget from an accessibility perspective? Or would this get messy?
Sounds like the down arrow should post the menu as its default (first) action. Then it would be up to GOK to detect the posting of the drop-down and either immediately present the items in a "menu" keyboard, or go to the main gok keyboard and allow the user to press UI Grab (depending on whether this drop-down appears as a new toplevel window or not, from GOK's perspective)
Created attachment 26084 [details] [review] gail patch This gail patch reports "press' as the first (i.e. default) action for buttons which contain a DownArrow. Does this patch allow gok to deal with this type of button?
Padraig, this patch is not fixing the problem for me. I'm not sure why. David H., have you tried it?
I'm currently trying to address Solaris issues, I'll have a check when I can.
I will investigate.
I have determined that the function gtk_menu_popup is being called but the menu is not popped up. Need to look further. I will leave the bug here for the present.
The problem is that when pointer grab is attempted when popping up the menu the grab fails. The error in AlreadyGrabbed. Is it possible that gok has the pointer grabbed?
I am virtually certain that GOK does not have the pointer grabbed; this happens according to the bug report even when GOK is not used in corepointer mode. More likely something is reentering in an unexpected way in gtk+, in Nautilus. GOK never does XGrabPointer, and if GOK is used in non-corepointer mode there should be no implicit grab taking place. GTK+ does a pointer grab when menus are posted, etc. but GOK isn't posting any UI elements that do explicit grabs.
Padraig: are you using GOK (or whatever test client you are using) in non-corepointer mode? I would think that at-poke would be unsuitable for demonstrating this problem for the reasons implied above (at-poke would do "Take Action" on GtkButton press, during which time X would be doing an implicit pointer grab).
I had been using gok in corepopinter mode. When I tried it with at-poke it worked correctly.
Padraig's patch fixes this for me, when in non-corepointer mode. In corepointer mode, of course, the dropdown menus cannot be used because they cause a pointer grab to occur (in gtk+).
Patch committed to CVS HEAD.
Just a complaint, I don't think this patch is good enough--changing togglebutton's default action just because nautilus needs it. The togglebutton will only emit "toggled" signal when it's *clicked*. If another application uses togglebutton with down-arrow on top, and it just listens to "toggled" signal, then GOK's UI grab function will not work properly with this application, because it just emitts a "pressed" signal to togglebutton. I don't think it's the common sense to listen to "pressed" signal when using togglebutton.
If you have a widget for which the current behavior does not work please log a bug.
See SUN's bugtraq 5083091, I have partially fixed it by setting the arrow-button's a11y name, but GOK still can't work properly with "press" as the default action. A simpified test-case is available at gal/gal/widgets/test-color.