Community
Participate
Working Groups
To reproduce: 1. Create a logic example diagram 2. Use cursor keys to navigate into Geometric shapes drawer. 3. Press space key on top of "Rectange Types" stack. 4. Press "alt-arrow-down" to open stack and use arrows keys to navigate to specific entry "3d Rectangle" and press enter to select it. NOTE: "3d Rectangle" is now selected. 5. Press enter. RESULT: It prompts for the type of rectangle to create. The menu item changes back to "Rectangle Types". It appears that selecting "3d Rectangle" did not really register. WORKAROUND: After selecting "3d Rectangle", navigate to another palette entry, then back to the "3d Rectangle" entry and it will work.
*** Bug 143070 has been marked as a duplicate of this bug. ***
Initial investigation shows the following... Assume we have a situation where "Tool A" is the 'primary' entry on a palette stack and "Tool B" is the entry I am trying to create via the keyboard. - When I select "Tool B" on the palette stack with the keyboard, PaletteViewer.setActiveTool() is being called with "Tool B". - Then when I press enter, to create an element of this type on the diagram, PaletteViewer.setActiveTool() is being called again with the "Tool A". The stack trace shows that in DomainEventDispatcher.dispatchKeyReleased() the focusOwner is "Tool A". I think the focusOwner should be "Tool B" at this point.
This is an issue in GEF. When the user presses the space button on a regular tool item on the palette, the PaletteViewerKeyHandler picks this up. In GraphicalViewerKeyHandler.keyPressed() this will call processSelect() which does: getViewer().setFocus(part); When the context menu is opened after ALT+DOWN is pressed on a palette stack item, the PaletteViewerKeyHandler does not seem to catch the key events anymore. When the users presses ENTER it looks as though the new tool they have chosen is selected; however, as indicated in my previous comment, the focusOwner in DomainEventDispatcher is not updated. I am proposing a fix to SetActivePaletteToolAction which will set the focus in the palette viewer to be the new tool the user just selected in the palette stack. See attached patch, but here are the changes I made to SetActivePaletteToolAction: public void run() { if (viewer != null) { viewer.setActiveTool(entry); // The PaletteViewerKeyHandler will not pick up key events when the // context menu is open for palette stacks so we need to indicate // that the focus needs to change to the tool entry that the user // has just selected. See GraphicalViewerKeyHandler.procesSelect(). EditPart part = (EditPart) viewer.getEditPartRegistry().get(entry); viewer.appendSelection(part); viewer.setFocus(part); } }
Created attachment 43271 [details] Proposed Patch
Purpose: Bugzilla#123760 Palette selection in group is not registered the first time using keyboard - Added code in the SetActivePaletteToolAction to set the focus to the appropriate palette editpart. Code Reviewed by: Committed and reviewed by Steve. How tested: 1. Create a logic example diagram 2. Use cursor keys to navigate into Geometric shapes drawer. 3. Press space key on top of "Rectange Types" stack. 4. Press "alt-arrow-down" to open stack and use arrows keys to navigate to specific entry "3d Rectangle" and press enter to select it. NOTE: "3d Rectangle" is now selected. 5. Press enter. Impact on QE: n/a Impact on Doc: n/a Impact on build: n/a Delivered to Stream(s): dev.eclipse.org:/home/tools (R32_maintenance) dev.eclipse.org:/home/tools (HEAD)
The patch fixes the test case, but it might not be the optimal fix. If other clients are calling PaletteViewer#setActiveTool(), they will still experience the bug since the fix was made outside of the Palette. The problem is that a draw2d figure has focus, and it becomes hidden, while maintaining focus. Another fix that might be closer to the source of the problem would be for the guy who hides that focused figure to fix things up. That guy is PaletteStackEditPart#activeEntryChanged(Object, Object). When the stack changes the on-top child, it should see if that child is selected, and if so transfer selection and focus to the new on-top child.
Given the already delivered fix resolves the specific accessibility use case, I am going to close this bugzilla. We should raise a new Bugzilla if we are concerned with the other use case.
Another minor concern might be that a GEF client has decided to use the SetActivePaletteToolAction to change the active tool. For example, to allow keybindings to activate an entry in the palette, which I think is why this action is public and not internal. If a client has done this, the patch will now select that entry, which may be inside a closed drawer. It doesn't make sense for an entry inside a closed drawer to be selected, and may throw exceptions since the entry's figure is detached from the viewer at that point. I'm simply trying to provide as much information as I can since there is little time left to get this change in the hands of clients.
