Community
Participate
Working Groups
Created attachment 230166 [details] stacktraces 4.3.0.N20130424-2000 I don't have steps to reproduce this in a fresh workspace, but it happens consistently in my dev workspace with these steps: - open two text files from the Package Explorer or Navigator view - make sure an editor is active - double-click the other file => expected: other file's editor is brought to top and active => was: other file's editor is brought to top, but then the view is activated again Bug 312568 and bug 394462 sound related, but they're both on GTK, and at least the latter is a bug in SWT. In this bug, E4's StackRenderer$ActivationJob is wrongly setting the focus here: java.lang.Exception at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.setFocus(PackageExplorerPart.java:779) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.delegateSetFocus(CompatibilityPart.java:190) at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:231) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:237) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:208) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:107) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.focusGui(PartRenderingEngine.java:759) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:585) at org.eclipse.e4.ui.internal.workbench.PartServiceImpl.activate(PartServiceImpl.java:548) at org.eclipse.e4.ui.internal.workbench.swt.AbstractPartRenderer.activate(AbstractPartRenderer.java:104) at org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer$ActivationJob.run(StackRenderer.java:221) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4145) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3762) ...
I can reproduce this on linux in 4.3.0.I20130423-0800 PW
> I can reproduce this on linux in 4.3.0.I20130423-0800 > > PW On Linux, you probably run into bug 312568, which has similar effects, but is not exactly the same as this bug.
Markus, I'm looking into what might be different between old and new workspaces...do you by chance have the 'single click' mode on in your dev ws ? I've just turned this on locally and now I see what you report...the first click opens the editor and the second one is putting the focus back onto the PE...
No, I exclusively work with double click mode, and my workspace still has this setting. Dani is the single-click guy :-) According to bug 45186 comment 33, single click mode should not activate the editor on the first click, but should also activate the editor on the second click. I attached a debugger again to ensure that I'm not tricked by a bouncy mouse button and that I really only press the mouse twice. For that, I installed a breakpoint in org.eclipse.swt.widgets.Widget#sendEvent(Event) line 1056 with condition: if (event.type == SWT.MouseDown) { System.out.println("down: " + new java.util.Date()); } return false; And here's the clue: With this breakpoint, I can also reproduce it in a runtime workbench! Looks like the delay from the condition evaluation is enough to trigger the bug in an otherwise unladen workbench.
Thanks for the info Markus, I'll give this a whirl...
Yep, I can repro now. It's interesting that if you make the PE the active view *before* issuing the double click that the bug doesn't manifest. I think you're correct that the activationJob seems to miss the second activation (first it sees the PE going active but then it should also see the editor going active after that...
The current 'asynch' code was introduced to prevent recursion when clicking on a tab that is *not* the currently selected tab in the stack (see bug 307199 for details). I've pushed a potential fix for this that removes the asynch code altogether: https://git.eclipse.org/r/12643 The new approach determines whether or not the tab is going to eventually switch and, if so, skip the SWT.Activate handling and allow it to be handled by the subsequent tab change...
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=847520d8d759b373e537eb8799e1b1714084c90e PW
Paul, should I mark this one FIXED since you've pushed the changes ?
Sure. We should verify it in tonight's I build as soon as possible. PW
Paul, could you please test this with last night's build as well? PW
Verified on Windows 7 - in I20130512-2000 with my dev workspace - in master with the slowdown breakpoint from comment 4 The code is also much nicer without the asyncExec.
As per Markus' comments, thanks !
