Issue 122363 - Key events handled twice
Summary: Key events handled twice
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 4.0.0-dev
Hardware: All All
: P2 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: winA11y
  Show dependency tree
Reported: 2013-05-22 08:49 UTC by Andre
Modified: 2014-01-06 15:04 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Andre 2013-05-22 08:49:27 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.
Comment 1 V Stuart Foote 2013-05-25 09:01:55 UTC

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.
Comment 2 V Stuart Foote 2013-05-27 21:07:56 UTC
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 direction
Comment 3 V Stuart Foote 2014-01-06 15:04:02 UTC
QA testing for Accessibility support shows mishandling of key events is causing issues with loss of object focus. 


bug 122251
bug 123933
bug 123934