GNOME Bugzilla – Bug 353532
[blocked] popup menu items not presented in java applications
Last modified: 2008-07-22 19:13:26 UTC
Run SwingSet2 application. Press Shift + F10 to activate popup menu. The menu items are not reported when navigating in the menu.
I ran SwingSet2 on Windows XP and used JavaFerret to determine the events being fired when a popup menu item is selected. Both "armed" and "focused" events are fired. It appears that Orca is not receiving the either state-change events.
Created attachment 72386 [details] [review] proposed patch Orca does not receive focus events from popup menus. This patch is a workaround for the problem.
Comment on attachment 72386 [details] [review] proposed patch >? orca/docs/man/Makefile >? orca/docs/man/Makefile.in >? orca/po/stamp-it >? orca/src/brl/.deps >Index: orca/src/orca/J2SE-access-bridge.py >=================================================================== >RCS file: /cvs/gnome/orca/src/orca/J2SE-access-bridge.py,v >retrieving revision 1.9 >diff -p -u -r1.9 J2SE-access-bridge.py >--- orca/src/orca/J2SE-access-bridge.py 23 Aug 2006 12:30:59 -0000 1.9 >+++ orca/src/orca/J2SE-access-bridge.py 7 Sep 2006 18:43:57 -0000 >@@ -150,6 +150,28 @@ class Script(default.Script): > - event: the Event > """ > >+ # When a root pane gets focus, a popup menu may have been invoked. >+ # If there is a popup menu, give locus of focus to the first menu >+ # item in the popup. >+ # >+ if event.source.role == rolenames.ROLE_ROOT_PANE and \ >+ event.type == "object:state-changed:focused" and \ >+ event.detail1 == 1: >+ >+ for i in range(0, event.source.childCount): >+ # Search the layered pane for a popup menu >+ if event.source.child(i).role == rolenames.ROLE_LAYERED_PANE: >+ popup = util.findByRole(event.source.child(i), >+ rolenames.ROLE_POPUP_MENU) >+ if popup.count() > 0: # should be len(popup) > 0: >+ # Set the locus of focus to the first popup menu item >+ item = util.findByRole(popup[0], >+ rolenames.ROLE_MENU_ITEM) >+ if item.count() > 0: # should be len(item) > 0: >+ orca.setLocusOfFocus(event, item[0]) >+ return >+ >+ > # In java applications the events are comming in other order: > # "focus:" event comes before "state-changed:focused" event > #
Created attachment 72387 [details] fixed syntax error in previous proposed patch
Created attachment 72388 [details] [review] forgot to run 'cvs diff' for new patch :-(
I'm curious about the patch - it seems as though it might not work properly if: 1) It were ever possible that the first item in the popup menu wasn't automatically selected (e.g., is it possible for an app to try to do something 'smart' when it pops up a menu?) 2) The first item was a submenu and not a menu item. Although I remember Java doing something 'unique' with respect to the state of the highlighted menu item, an alternative approach here might be to look at the selection state (or whatever state it is that Java uses) to determine which, if any, of the objects in the popup menu is the locus of focus.
This patch seems like a bad kludge. Surely the right fix is elsewhere? (in the java access bridge for gnome, or in the JRE/Swing?) Failure to emit focus notification is a major no-no. If we _do_ have to work around a serious JRE/JDK bug here, I think the kludge should go into the java-access-bridge (equivalent logic to the above patch, _if_ indeed it works for all cases). I share Will's concern about the implementation; I am pretty sure that the first item in popup menus is not always selected, etc.
Created attachment 73588 [details] [review] Workaround for java-access-bridge bug, sets locus of focus to the first armed popup menu item The revised workaround sets locus of focus to the first armed popup menu item, rather than just setting the locus of focus to the first popup menu item.
*** Bug 352617 has been marked as a duplicate of this bug. ***