Apache OpenOffice (AOO) Bugzilla – Issue 122363
Key events handled twice
Last modified: 2014-01-06 15:04:40 UTC
On some occasions key events for focus traveling are handled in two different places. One example: 1. Open a new Calc document. 2. Open the search dialog (Ctrl+F). 3. Click on "More Options" to expand the options part of the dialog. 4. Click on the Backwards check box to place the focus on this button (alternatively use F6, Tab, and cursor keys to put the focus on this button; checking it is not necessary) 5. Press (and release) the DOWN key three times. Expected result: Focus is on the "Search for Styles" check box. Actual result: After second DOWN Focus stays on the "Similarity search", third DOWN moves the current cell in the Calc document on row down. A similar behavior can be observed with Writer documents and the Search dialog. Another example is bug 122251.
@Andre, Loaded the revision 1485730 based build, seems to have introduced additional problem with focus traveling with <RIGHT> cursor key movements. Before, it had been only <DOWN> key movements. On a Linux Fedora 18 install of AOO400m2(Build:9701) - Rev. 1485784 2013-05-24_04:10:24 - Rev. 1485930 To reproduce: 1. Open a calc spreadsheet 2. <F6> to Sidebar deck title bar 3. A series of <RIGHT> cursor movements will pass out of deck onto Tab bar configuration menu button. It then shifts the active cell of sheet one cell to Right. 4. A series of <DOWN> cursor movements will pass out of deck onto Tab bar configuration menu button. It then shifts the active cell of sheet one cell Down. 5. move <LEFT> off configuration menu button and then <RIGHT> back onto it and active cell shifts Right again. 6. move <UP> off configuration menu button to last content panel of deck and then <DONW> onto configuration menu button, active cell shifts Down again. 7. will repeat with any mix of <RIGHT> or <DOWN> arrivals onto the Tool bar configuration menu button. Never moving active cell Left or Up.
Ugly! So this GUI object issue affects more than just Sidebar--this cursor focus "bleed over" from the active frame onto objects in external non-focus frame. I'm sure it is the same root cause but I find it manifests in two flavors: 1) if able to use cursor to move between GUI components -- mishandle appears to occur when moving with <DOWN> or <RIGHT> cursor keys from one active element of a composite panel to another. Leaks when pressing the cursor as it crosses between the panel components. All four cursor keys can navigate but only the <DOWN> or the <RIGHT> cursor key is passed and processed external to the panel with focus Observed in composite panels: Sidebar panel, <ALT>+V S -- (C) Deck title bar -> Tab bar Number format content panel -> Tab bar 2) if can only use tab to move between GUI components -- mishandle appears to occur within an element of a composite panel, either a vertical list or a horizontal list. Leaks when reaching the last list item. But ALL four cursors will leak at the boundary--most obvious in a Calc session. Observed in composite panels Find & Replace panel, <CTL>+F -- (C, W) Find toolbar Replace toolbar More Options Backwards-Regular expressions-Similarity search Search for Styles Search Search direction
QA testing for Accessibility support shows mishandling of key events is causing issues with loss of object focus. See: bug 122251 bug 123933 bug 123934