Apache OpenOffice (AOO) Bugzilla – Issue 48639
Gok open 2 instances of a pane when menu used
Last modified: 2005-05-30 14:33:50 UTC
- JDS 34b + OOom97 - GOK: Menu - New - Text Document -> 2 documentrs are created Note: same for Open, Export and Save As dialogs
Set accessibility keyword
ES->OBR: please dispatch to the responsible engineers. Thanx!
cc'ing tbe.
When performing the 'select' action of the 'File/New/Text Document' menu item by using the Accessiblity Workbench, only one document is created.
What gok does is it calls XAccessibleSelection::selectAccessibleChild() on the menu before it actually runs the action on the menu item, which currently has the same effect as XAccessibleAction::doAccessibleAction(). So from a OOo perspective, this call sequence appears as a duplicate call to doAccessibleAction(). The behaviour in GNOME apps is different: e.g. in gedit, a menu item shows it's description in the status bar when selected and that's it. Unfortunatly I could not check in Java apps, because their menu bar currently doesn't show up in at-poke (at least for me).
*** Issue 48640 has been marked as a duplicate of this issue. ***
'select' shouldn't be the same as 'activate', in this context. For instance, if you mouse over a menu, and the various choices prelight, they are being 'selected' but not activated. So the implementation of XAccessibleSelection::selectAccessibleChild() should be changed for menu items.
Bill, using AccessibleSelection to 'add' a menu item to the selection of it's parent menu has always resulted in that item being activated in Java/Swing. You can see this with the Monkey tool. Select a menu in the accessible tree of a Swing app and bring up the Selection panel for it (e.g. File in SwingSet2). Choose a selectable child and click "Add" to add it to the selection, and that will activate the menu item. This is different for things like lists of course. But for menus we mirror the standard GUI notion of "selecting from a menu".
If OOo is correctly emulating Java accessibility here, I think this issue needs to get addressed in the gnome-java-bridge.
Peter:those aren't the semantics of at-spi. Selection and activation are definitely disjoint for both menus and lists. Similar bugs have been fixed in the past, IIRC in java-bridge for gnome too. If OOo isn't working correctly, then I suggest that it isn't emulating Java 100%, since currently GOK doesn't result in multiple activations for Java menus in JDS.
Bill, I have just reproduced the same behavior OOo shows with jmplay and GOK: "Menus - File - New Player" opens two new player windows. So the code in the gnome-java-bridge that handles the different semantics of menus in at-spi and JAA seems to got broken by some other change.
interesting, this doesn't happen on my system (running Java 1.5.0_02 and JMFPlayer from an old Cinnabar build (30?)
My system runs plain Cinnabar 35 (including java 1.5.0_03). Maybe anyone running the same configuration can confirm ?
Oliver - I'm seeing some inconsistencies with Java -sometimes I see the "double activation" that you are reporting even with my JVM. So I probably should make some tweaks to the Java bridge.
If it may help: yes I can exactly reproduce what Oliver is describing with the same config (JDS 35, Gok, jmplay).
Bill, I don't understand the issue here. GOK will see a File menu (for example) that implements AccessibleSelection, and an About menu item (for example) that implements AccessibleAction. Telling File via AccessibleSelection to select "About" happens to do the same thing as telling About via AccessibleAction to "click". Why cannot GOK distinguish between the two and only call one of them at it's choice? I don't see a problem here. What am I missing?
well, that's not the way gok works. The menu buttons are not special-cased in this way, they act like other actionable items. For a number of reasons having to do with the way various toolkits work, you often have to select items whose parent implements Selection before invoking an action on that item. These two things are totally orthogonal in at-spi.
Hmm... Frankly need to select an object before AccessibleAction works seems odd to me (if not a bug). Also calling a menu item a "menu button" seems wierd to me - not a GUI concept for me. But separate from that, it is still the case that in Java you (a) don't need to select an item before you can call its Action, and (b) menu item selection == invocation. If you have a strong desire for this to appear differently in AT-SPI, then it must be dealt with in the bridge.
on reflection Peter I don't know if it's possible to deal with this in the bridge. The need to select before activation is the sort of thing that would be closed instantly as NOTABUG by an app or toolkit person IMO. It has come up a few times. by "menu button" I am referring to the GokButton representing a menu item. If menu item selection == invocation in Java, then the menu should not implement AccessibleSelection, IMO, since that is redundant with AccessibleAction.
I have logged CR6274349 for the jmplay issue in Cinnabar. As soos as there is a fix for this one, we need to re-evaluate this issue again to check whether it there is an additional Java compatibility problem in OOo. Adjusting target.
This issue vanished with gok 1.0.5-38 (cinnabar36).
Closing as "not OOo".