Community
Participate
Working Groups
[I20061128-0800] Sometimes, when opening a compare editor from the sync view, other random shells (e.g. Firefox, Notes...) come to the front. This seems to be related to showing progress in a dialog. It does not happen if the compare results are displayed fast enough.
*** Bug 168516 has been marked as a duplicate of this bug. ***
*** Bug 163078 has been marked as a duplicate of this bug. ***
Boris and I tracked this down to the ProgressManager. The problem is that the Jobs progress monitor stays open after the job finished. The compare code then calls IProgressServive#busyCursorWhile which causes shell deactivation. This hits an SWT workaround which throws focus to an OS shell. I'm pasting the stack since I'm sure we'll forget all this by the time we get back from holidays. Thread [main] (Suspended (breakpoint at line 746 in Control)) Shell(Control).fixFocus(Control) line: 746 Shell(Control).setEnabled(boolean) line: 2409 Shell.setEnabled(boolean) line: 1261 ProgressManager.setUserInterfaceActive(boolean) line: 1235 ProgressManager.access$4(ProgressManager, boolean) line: 1225 ProgressManager$3.run() line: 889 BusyIndicator.showWhile(Display, Runnable) line: 67 ProgressManager.busyCursorWhile(Runnable, ProgressMonitorJobsDialog) line: 925 ProgressManager.busyCursorWhile(IRunnableWithProgress) line: 900 ProgressManager.run(boolean, boolean, IRunnableWithProgress) line: 1108 CompareEditor$EditorCompareContainer(CompareContainer).run(boolean, boolean, IRunnableWithProgress) line: 81 ModelCompareEditorInput(CompareEditorInput).run(boolean, boolean, IRunnableWithProgress) line: 948 JavaMergeViewer(TextMergeViewer).doDiff() line: 2869 JavaMergeViewer(TextMergeViewer).update(boolean) line: 5068 JavaMergeViewer(TextMergeViewer).updateContent(Object, Object, Object) line: 2332 JavaMergeViewer(ContentMergeViewer).internalRefresh(Object) line: 703 JavaMergeViewer(ContentMergeViewer).inputChanged(Object, Object) line: 603 JavaMergeViewer(ContentViewer).setInput(Object) line: 251 JavaMergeViewer.setInput(Object) line: 134 CompareEditorInput$2(CompareViewerSwitchingPane).setInput(Object) line: 254 CompareEditorInput$12.run() line: 602 BusyIndicator.showWhile(Display, Runnable) line: 67 ModelCompareEditorInput(CompareEditorInput).feed1(ISelection) line: 597 ModelCompareEditorInput(CompareEditorInput).feedInput() line: 592 ModelCompareEditorInput(CompareEditorInput).createContents(Composite) line: 443 CompareEditor.createCompareControl() line: 347 CompareEditor.access$2(CompareEditor) line: 320 CompareEditor$3.run() line: 281 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123 Display.runAsyncMessages(boolean) line: 3442 Display.readAndDispatch() line: 3082 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 1942 Workbench.runUI() line: 1906 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 424 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.run(Object) line: 95 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 85 NativeMethodAccessorImpl.invoke(Method, Object, Object[]) line: 58 DelegatingMethodAccessorImpl.invoke(Method, Object, Object[]) line: 60 Method.invoke(Object, Object[]) line: 391 EclipseAppContainer.callMethod(Object, String, Class[], Object[]) line: 522 EclipseAppHandle.run(Object) line: 147 EclipseAppLauncher.runApplication(Object) line: 104 EclipseAppLauncher.start(Object) line: 74 EclipseStarter.run(Object) line: 354 EclipseStarter.run(String[], Runnable) line: 170 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 85 NativeMethodAccessorImpl.invoke(Method, Object, Object[]) line: 58 DelegatingMethodAccessorImpl.invoke(Method, Object, Object[]) line: 60 Method.invoke(Object, Object[]) line: 391 Main.invokeFramework(String[], URL[]) line: 473 Main.basicRun(String[]) line: 417 Main.run(String[]) line: 1121 Main.main(String[]) line: 1096
Mine! I have a hack/fix for this.
Fixed > 20070201 Boris, I expect to go through a round of touch ups on this one. Cross your fingers.
Wait. !#$%!@$#% Eclipse.org is down and won't accept my code.
Now it's in.
See bug 172888 for the first of the fallout.
*** Bug 35768 has been marked as a duplicate of this bug. ***
I'm still seeing this problem in 3.3.1.1.
> I expect to go through a round of touch ups on this one. Ok, a touch up. Does a random shell from another application come to the front or is it an Eclipse window?
> Ok, a touch up. Does a random shell from another application come to the front > or is it an Eclipse window? I was using something based on eclipse, and Lotus Notes V7 came to front.
You were using something based on Eclipse 3.3.1.1 and another application (Notes V7) came to the front. The bug that we fixed happened when Windows chooses the next shell to bring to the front: /* * Feature in Windows. When the active shell is disposed * or hidden, Windows normally makes the parent shell active * and assigns focus. This does not happen when the parent * shell is disabled. Instead, Windows assigns focus to the * next shell on the desktop (possibly a shell in another * application). The fix is to activate the disabled parent * shell before disposing or hiding the active shell. */ We have attempted to work around the scenario and must be missing a case. It is also possible that your application is calling Shell.forceActive() (which calls the win32 API SetForegroundWindow() and this is forcing the window to the top). Need more to go on to debug this. Can you get a reproducable case?
