| Summary: | [Progress] Modal dialogs deadlock during launching an Eclipse app | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alexei Alexandrov <alexei.alexandrov> | ||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | baumanbr, darin.eclipse, public, wassim.melhem | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.3 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 160745, 167134 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Alexei Alexandrov
Created attachment 47833 [details]
The problem screenshot
This type of launch is from PDE. This is actually a platform issue - we should not be opening the user job dialog when there is a dialog already open. Brian are you opening this dialog on the same shell as the debug dialog? if so then our API doesn't block if it is on the same shell - we should rethink that one. I am not sure which shell we end up opening against (we might find the shell incorrectly). Here is the code we use to get the shell: Display display = Display.getCurrent(); if (display == null) display = Display.getDefault(); display.getActiveShell() Darin, just wanted to give you a heads up as we discussed this issue. I believe the launch dialog box is closed before Debug schedules the job. If this is the case, I believe PDE (with the code above) would get the main workbench shell. Debug uses the following lines of code to get the shell to pass into the .showInDialog function. IWorkbench workbench = DebugUIPlugin.getDefault().getWorkbench(); workbench.getActiveWorkbenchWindow().getShell() It would not surprise me if both of them use the same main workbench shell. If this were the case, we might expect behavior similar to this bug report, right? BTW it is a lot safer to use something like the following (this is from ProgressManagerUtil)
IWorkbenchWindow window = PlatformUI.getWorkbench()
.getActiveWorkbenchWindow();
if (window == null) {
IWorkbenchWindow[] windows = PlatformUI.getWorkbench()
.getWorkbenchWindows();
if (windows.length > 0)
return windows[0].getShell();
} else
return window.getShell();
The problem with getActiveShell is that you can grab a lot of potential shells. If the active shell is closed on you you might lose the dialog or you may get inconsistent parents.
*** Bug 109120 has been marked as a duplicate of this bug. *** Display display = Display.getCurrent();
if (display == null)
display = Display.getDefault();
display.getActiveShell()
is frequently different from
DebugUIPlugin.getDefault().getWorkbench();
workbench.getActiveWorkbenchWindow().getShell()
shells can be used for content assist, tooltips, animations etc.
Where is the code where you call getActiveShell()?
We call it when launching if we need to display a dialog box. The Debug Launching Dialog is already closed, so the active Shell should be the workbench window (as far as I believe). So it would be safer for PDE to do something similar to comment 7 when it needs a Shell upon which to open a dialog during the launching process, right? As I said the active shell could be different becuase of a user action (i.e. if you have animations on the animated shell could be the active one). Code like comment 7 is much safer - see Bug 160745 If 167134 is implemented this will no longer be an issue Bug 167134 has cleared this up. Verified in I20070319-1005 |