Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 331698

Summary: Focus not restored properly when breadcrumb bar is used
Product: [Eclipse Project] Platform Reporter: Scott Kovatch <skovatch>
Component: SWTAssignee: Scott Kovatch <skovatch>
Status: RESOLVED FIXED QA Contact: Silenio Quarti <Silenio_Quarti>
Severity: normal    
Priority: P3 CC: markus.kell.r
Version: 3.7   
Target Milestone: 3.7 M4   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:

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.