Community
Participate
Working Groups
Update is experiencing issue during installation of new features/plug-ins. This done using Jobs API. The way it should work: 1) download a feature in a Job: org.eclipse.update.internal.ui.wizards.InstallWizard2.launchInBackground which has progress monitor 2) install feature from a job listener org.eclipse.update.internal.ui.wizards.InstallWizard2. UpdateJobChangeListener which launches a window that will prompt user if it wants to install or not Problem is although these two steps should happen sequentially second steps start before progress monitor from step one is gone and it stays behind it. One has to put progress monitor in background to continue. This looks very bad for update. To test whether it’s update I took m6 and replace it’s update jars with update jars from rc1 and behavior was correct so this must be coming from outside of update. I was told by my colleague that this behavior was correct in nightly build from 2006-10-04. As a note I saw similar behavior in other components for instance in cvs perspective if one tries to check out project that already exist in the workspace conformation window will be behind progress window. I am not sure that the problem is in Jobs API it might be with z-ordering of windows in SWT (that’s why I am cc-ing Veronika_Irvine@ca.ibm.com) too or somewhere else. So, be free to move this bug to more appropriate component One of the update bugs that is caused by this is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=137207
While fixing the 'Cancel' behaviour for mirror dialogs, I have had another encounter with this problem. It seems to me that something changed in the timing of the progress dialog that is opened by the UI to allow the user to monitor the job or move it into the background. It looks as if both the progress dialog and the mirror dialog are opened using the same workbench window as the parent shell. Both calls to open the dialogs is executed on the GUI thread, so the change from 'syncExec' to 'asyncExec' in the UI could have done this. Here is my theory (based on nothing but ethernal sunsine of my spotless mind): Before: 1) Job is started 2) Progress dialog is opened using syncExec. It immediately opens 3) Job is executed. As part of the job, MirrorDialog is opened. It appears on top of the progress dialog. Now: 1) Job is started 2) Progress dialog is opened using asyncExec. The event is appeneded to the event queue. 3) Job is executed. As part of the job, MirrorDialog is opened. 4) Posted event from (2) is finally executed. It appears on top of MirrorDialog. Being modal, it blocks MirrorDialog. Is this how it happened or something entirely different is at play?
Errata: Both calls to open the dialogs is executed -> are executed sunsine ->sunshine
Hmm, after some sniffing around, I suspect this is related to the fix for bug 55817 that was committed on April 11th. Tod, I suggest rolling back that fix since this side-effect is much worse than Stefan's original problem.
I.e., Stefan's patch essentially gives the progress dialog a random parent (the current active shell). If the current active shell is a modal dialog waiting on user input, then the user is forced to close the progress dialog to get at the modal shell underneath.
Right. I think a better guess would be: if there top shell is a modal dialog, go up the shell hierarchy and make yourself the child of the first non-modal shell. In addition, make sure Z order is such that you are not on top of any currently open modal dialog.
That may work, but I've seen enough modal shell interaction deadlocks to know this is scary stuff and it's hard to get it right. At this point, I think we should go back to a null parent shell for the progress dialog... it has been that way for two years, and apart from Stefan's multiple monitor issue it has worked ok. A better fix for bug 55817 could be investigated after 3.2.
A big +1 from Update. We got many hate bugs about this problem.
I think the answer is more like we handle the ProgressMonitorFocusJobDialog (the internal one with no RunInBackground) - we should be calling ProgressManagerUtil.getNonModalShell() - this will never parent off of a modal dialog then. I have not changed any syncExecs to asyncExecs for user jobs - the dialog opening has always been a UIJob. I think Dejan has the right iedea - we should use the available non modal shell. ProgressManagerUtil#getNonModalShell looks for an available workbench window and if there isn't one returns null. Overall this is a better solution than a rollback anyways as we will choose the right non modal shell when there is one to choose. Here is the implementation of ProgressManagerUtil#getNonModalShell 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(); return null; Adding McQ for PMC approval/SWT expertise.
I'm not particularly happy with the idea of assigning a random parent (even if it is a top level shell). Ask Steve about all of the multi-window bugs that he sees -- I'd rather not increase the potential for them. I haven't seen the original bug, but if it's just a dialog with a null parent opening on the wrong window, then the right fix seems to me to be to figure out which Monitor the dialog should open on (i.e. pick which ever one holds the shell you would have parented it on), and force it to be created there (but still with no parent). If that's not possible, then just pull out the patch and mark this as 3.2.
After sleeping on this I realized there is a more general problem to be addressed - the issue of two modal dialogs. If code from a job opens a modal dialog while there is another modal dialog is already open there is always a potential for lockout - modality is very unreliable when two shells are fighting for it. In the progress support we have ProgressManagerUtil#safeToOpen(ProgressMonitorJobsDialog dialog, Shell excludedShell) which is something that constantly checks that there is nothing modal up before we bring up a user job. There is currently no API to do this in general for dialogs. I am going to rollback Bug 55817 as it is making this problem worse. I have opening 137936 to track the functionality I am describing above. I'll leave this open so that we can verify the rollback solves this problem
Read I have opened Bug 137936 to track the functionality I am describing above.
I am have rolled back Bug 55817 in build >20060421
*** Bug 137269 has been marked as a duplicate of this bug. ***
Marking as FIXED
Marking verified
