GNOME Bugzilla – Bug 349690
Unable to access panel's right click menu via ATK
Last modified: 2015-03-24 13:01:00 UTC
I wanted to use sniff to explore right-click menus (specifically, sniff adding and removing things from the panel) but it isn't possible. I can right-click the panel but gnome automatically closes the menu when I switch back to sniff. There isn't a clear way to fix this but talking to zack, it's a valid concern.
Sounds to me like this is a bug in gnome-panel: is the action of right-clicking on the main area of a panel accessible in any way? Should it expose a "menu" action to bring up the context menu? I've seen this with gnome-panel-2.14.1-2 (on Fedora) - Tim: which version are you using? Reassigning from dogtail to gnome-panel and adding "accessibility" keyword
(renaming summary to make problem more clear)
Thanks for helping me with this, Dave. I've got gnome-panel-2.14.2-1.fc5.1 installed.
Erm, you'll need to help me here :-) Which right-click menus? What is sniff? What should be done to fix this?
note, you don't need to right click on a panel to get it's menu. you can ctrl-alt-tab to the panel to give it focus and then use ctrl-f10 to pop up the context menu.
The right-click panel menu that has "Add to Panel..." "Properties" and "Delete this Panel...". sniff is a AT-SPI browser that comes along with dogtail ( http://people.redhat.com/zcerza/dogtail/ ). Normally applications have a "menu" action in sniff that lets me get to the right-click menu. The desktop has this menu so I can get to "Create Folder" "Create Launcher" etc just fine. I'm not really much of a gnome coder so I don't really know how to fix this issue.
As Ray pointed out, you can access this menu without the mouse. I don't understand how this is different from all the right-click menus we have everywhere on the desktop.
I'm not sure what's different between Nautilus's right-click and panel's right-click. I wish I knew more about gnome applications so I could be more clear. Dave Malcolm is away for now, but when he comes back he can probably provide clearer info. Until then I'm not sure how to progress...
Ping for Dave.
This may be related to something I'm seeing, namely you cannot access many of the panel's right-click menu via screen readers such as Orca. The menu appears, you can arrow in it, but as far as Orca is concerned, it's not there (so the contents are not spoken, which means it's not usable for people who are blind). I'm not sure what the difference is either, but it seems that we normally get focus events in menus and that we are not getting them for the panel's right-click menus. Try comparing a couple of menus using AT-POKE to log focus events. For instance, if I turn on event logging and then press Alt F1 to get into the Applications menu and then arrow around, AT-POKE logs: generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Accessibility:Accessibility...(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Accessories:Desktop acces...(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Games:Games and amu...(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Graphics:Graphics appl...(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Internet:Programs for ...(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Applications:(0) (0) generic event 'focus:' A|co|ac|te|se:menu:Office:Office Applic...(0) (0) If I turn on event logging, use Control Alt Tab to move to the bottom panel, Tab to the trash icon, press Shift F10 for the right-click menu, and arrow around, AT-POKE logs ... nothing. Using the mouse, btw, makes no difference in terms of what focus events we get. This lack of events is also true for the right-click menus associated with the weather applet, network monitor, and volume control. Interestingly enough, the problem does not exist with the system clock -- you get plenty of focus events for that menu. Assuming this is the same problem as described in the original bug, please consider upgrading the severity. If it's a different issue and/or should be filed elsewhere, please let me know. Thanks!!
This should be the same bug that you are experiencing, as sniff/dogtail uses accessibility hooks to work its magic.
Having done a bit more investigation, my issue seems to be a bit different. See http://bugzilla.gnome.org/show_bug.cgi?id=400709#c3. Sorry about that!
Marking as NEEDINFO since I still don't know what's the issue here.
Still nobody to explain what's the issue? I'm going to close the bug soon :-)
This isn't really a bug, actually. Slightly separately, Vincent, on the AT-SPI side of things, when the context menu is created, it's created as an Accessible with the 'window' role, and its parent is the Application object representing gnome-panel. Do you know if it would be feasible to give the context menu the 'menu' role, and for extra credit make it the child of the widget that was right-clicked-on to create the menu? Should I file that as a separate bug? This one should probably be closed, though.
(In reply to comment #15) > This isn't really a bug, actually. Ok. > Slightly separately, Vincent, on the AT-SPI side of things, when the context > menu is created, it's created as an Accessible with the 'window' role, and its > parent is the Application object representing gnome-panel. Do you know if it > would be feasible to give the context menu the 'menu' role, and for extra > credit make it the child of the widget that was right-clicked-on to create the > menu? Should I file that as a separate bug? Yes, please file a new bug. And I have absolutely no idea how to do what you're asking :-) I would have hoped GTK+ would handle this automatically. But it's certainly doable. All the code for the context menu is in panel-context-menu.c.