Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 331698 - Focus not restored properly when breadcrumb bar is used
Summary: Focus not restored properly when breadcrumb bar is used
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.7   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: 3.7 M4   Edit
Assignee: Scott Kovatch CLA
QA Contact: Silenio Quarti CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-02 12:08 EST by Scott Kovatch CLA
Modified: 2010-12-07 14:25 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Kovatch CLA 2010-12-02 12:08:08 EST
Focus is not being set/restored properly when using the breadcrumb bar.

This is fallout from bug 330749 - Markus found this bug while using the N20101201 build.

- In a Java Editor, enable the breadcrumb (e.g. Navigate > Show in Breadcrumb)
- click the last black arrow in the breadcrumb
- click another member
=> focus is in the main toolbar; should be in the editor's text area
 
When you set a breakpoint to Control#setFocus() with hit count 2, you see that
the focus goes to the StyledText (it was on the breadcrumb tree before). Then
set an access&modification breakpoint on Decorations#savedFocus and resume.
When that breakpoint is hit, you see that Shell#windowDidResignKey() is called
on the workbench window, and this destroys the contents of savedFocus for that
shell.
Comment 1 Scott Kovatch CLA 2010-12-02 14:32:01 EST
Focus in Cocoa is per-shell, not global. saveFocus() is just getting the first responder for the NSWindow, finding the corresponding Control, and then saving that as the focused control for the Shell.

The problem appears to be in Control#forceFocus(), when Similar to other platforms, it sets the saved focus to itself, performs some checks, sets the saved focus to null, and then actually does the focus transfer. But then it calls shell.bringToTop(), which is indirectly causing windowDidBecomeKey to be called. The saved focus is null at this point, so restoring focus fails. That means traverseGroup is now called, and the first group is the toolbar -- and the toolbar is now focused.

forceFocus continues and sets the saved focus back to the StyledText, but at that point it's too late -- the focus has already moved.

Carbon has the same logic, but in Carbon's case, calling SelectWindow() just posts a kEventWindowActivated event to the event queue, which gets handled after the current event finishes, so the saved focus is properly set when the Shell attempts to restore focus. In Cocoa, makeKeyAndOrderFront() is immediate, so the saved focus is null when windowDidBecomeKey is called.

Fix is to call bringToTop after re-saving the focus to the control.

Fixed > 20101202.