Community
Participate
Working Groups
3.6 RC2, broken during 3.6 M3 (works in 3.5.2) When I click a link in a not yet enriched hover (be fast to make sure it doesn't get enriched before you click), then the hover shell closes immediately and does not give the focus back to the editor. Steps to reproduce: 1. paste this into Package Explorer of new workspace public class ClassParent { public void foo1() { } } public class ClassChild extends ClassParent{ /** * @see #foo1() */ public void foo2() { foo1(); } } 2. hover over foo2() and quickly click on foo1() NOTE: If you are not fast enough then you have to close and reopen the editor as the bug can only be seen the first time.
Seems to work on Linux. Maybe caused by fix for bug 275890 and bug 276065.
Steps to reproduce reliably in I20100523-0800: - Preferences > Text Editors: When mouse moved into hover: Enrich on click - paste to Package Explorer: /** * @see java.util.Collections */ public class HyperlinkTest { } - hover over HyperlinkTest - click the link
Reproduced in 3.6M3 with SWT v3612. Does not happen with SWT v3611d. Bug 275890 does not affect this problem. The bug appears with IE.java 1.54 (from bug 289470). The new Runnable from setText(String) line 1011 causes an unexpected FocusOut event later from OleFrame$2.run() line: 154, which makes StickyHoverManager$Closer.handleEvent(Event) close the rich hover control: StickyHoverManager$Closer.handleEvent(Event) line: 267 EventTable.sendEvent(Event) line: 84 Display.filterEvent(Event) line: 1196 WebSite(Widget).sendEvent(Event) line: 1001 WebSite(Widget).sendEvent(int, Event, boolean) line: 1026 WebSite(Widget).sendEvent(int, Event) line: 1011 WebSite(Widget).notifyListeners(int, Event) line: 769 OleFrame$2.run() line: 154 Display.runTimer(int) line: 3948 Display.messageProc(int, int, int, int) line: 3140 OS.DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessage(MSG) line: 2424 Display.readAndDispatch() line: 3476 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2404
The stack in comment 3 is not the real problem of this bug. That one only happens if I set a breakpoint in IE.java 1.80 line 1417 (before the Runnable is executed), and then resume from the first hit. The 'display.getFocusControl()' in OleFrame#initCheckFocus(Display) still looks scary... The real problem can be seen by setting a breakpoint at the first line of StickyHoverManager.Closer#focusLost(FocusEvent). After clicking the link, the resizable hover shell gets a WM_ACTIVATE message, and in Shell(Decorations).WM_ACTIVATE(int, int) line: 1686, it sends an SWT.Deactivate event for the resizable hover shell, since 'display.findControl (lParam)' returned the fixed-size hover shell. This SWT.Deactivate event is the unexpected one: StickyHoverManager$Closer.focusLost(FocusEvent) line: 222 AbstractInformationControl$7.handleEvent(Event) line: 685 EventTable.sendEvent(Event) line: 89 Shell(Widget).sendEvent(Event) line: 1053 Shell(Widget).sendEvent(int, Event, boolean) line: 1077 Shell(Widget).sendEvent(int) line: 1058 Shell(Decorations).WM_ACTIVATE(int, int) line: 1686 Shell.WM_ACTIVATE(int, int) line: 2114 Shell(Control).windowProc(int, int, int, int) line: 4157 Shell(Canvas).windowProc(int, int, int, int) line: 341 Shell(Decorations).windowProc(int, int, int, int) line: 1637 Shell.windowProc(int, int, int, int) line: 2038 Display.windowProc(int, int, int, int) line: 4873 OS.$$YJP$$DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessageW(MSG) line: not available OS.DispatchMessage(MSG) line: 2459 Display.readAndDispatch() line: 3655 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2629 I have a snippet that shows that this only occurs when the if (_getUrl().equals(ABOUT_BLANK)) {..} in IE#setText(String, boolean) is there, but it doesn't happen if I comment that out (i.e. revert bug 289470). The snippet is currently unreadable -- I'll attach a cleaned version in a minute.
Created attachment 170072 [details] SnippetBrowserFocusOutBug314432.java To see all Activate/Deactivate events, just uncomment this line: // addDisplayFilters(display);
Created attachment 170076 [details] patch Removing this block that made the problem appear actually looks to be a valid fix, as the original case that it was fixing (bug 289470) now works in HEAD without it. Doing this effectively reverts the process of handling consecutive Browser.setText() calls to what it previously was for several releases, which is the safest path to follow, especially given that 3.6RC3 is wrapping up soon.
+1 for RC3.
fixed > 20100526
Verified with I20100527-1700 on Windows XP and Windows 7.
