Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 365753 - [QuickAccess] changes focus which each arrow key causing lots of distracting flashing
Summary: [QuickAccess] changes focus which each arrow key causing lots of distracting ...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.2   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Dean Roberts CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 366107 (view as bug list)
Depends on:
Blocks: 320673
  Show dependency tree
 
Reported: 2011-12-06 10:35 EST by Dean Roberts CLA
Modified: 2012-02-13 15:15 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dean Roberts CLA 2011-12-06 10:35:56 EST 
1) Open quick access
2) Type a letter to get a populated drop down.
3) Use the arrow key to scroll up and down in the drop down.

The focus is constantly switching from the tree back to the search field text widget.

This causes the window trim to get and loose the focus look with each key press.  It is very distracting and flashy.
Comment 1 Dean Roberts CLA 2011-12-09 08:54:55 EST 
On the surface, this behaviour was "added" by the fix for bug 364029.  Specifically, by what is described in comment #2.  It would seem that there are, in fact adverse effects on Windows.

Before that change was made, using the arrow keys to scroll in the table would set focus to the table and away from the text widget.  This had the (unreported) problem that you could not type a bit, scroll a bit and then resume typing ... since the text widget does not have focus.

The key handlers for scrolling in the table are in QuickAccessContents.hookFilterText().  When handling the up and down arrows, the code explicitly calls table.setFocus().

I'm wondering if there is really a requirement to set the focus to the table.  Perhaps the focus could be left alone.  Using the enter key for table selection is still supported because this method also hooks the return key and performs handleSelection.

Commenting out the table.setFocus() calls seems to give us the desired behaviour on Windows.  Scrolling in the table with the arrow keys leaves the focus on the text widget which fixes this defect and, in my opinion, improves on the original behaviour.
Comment 2 Dean Roberts CLA 2011-12-09 09:12:19 EST 
*** Bug 366107 has been marked as a duplicate of this bug. ***
Comment 3 Dean Roberts CLA 2011-12-09 09:38:58 EST 
I believe I have a fix for this which I will release once the M4 build is out the door.