| Summary: | [QuickAccess] changes focus which each arrow key causing lots of distracting flashing | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dean Roberts <dean.t.roberts> |
| Component: | UI | Assignee: | Dean Roberts <dean.t.roberts> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | overholt, remy.suen |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 320673 | ||
|
Description
Dean Roberts
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. *** Bug 366107 has been marked as a duplicate of this bug. *** I believe I have a fix for this which I will release once the M4 build is out the door. |