Community
Participate
Working Groups
Build Identifier: M20090211-1700 On Windows XP, make sure the "Group similar taskbar buttons" item is checked in taskbar properties dialog. Launch eclipse and make sure there are documents in it so that you can edit them. Create some new eclipse window from eclipse main menu item "Window -> New Window", and modify one one document in every window but don't save, make sure those elipse windows are grouped in statusbar. right click it with mouse on taskbar and select "Close Group", you can see that there is a "Save Resource" dialog pops up to check whether you want to save the modified document, choose no, then only one window which pops up "Save Source" dialog is closed, but other windows are still here. BTW: Win7 has this problem too. In Windows 7, the dialog which asking you save document or not, popped up once and then disappeared. Click any Eclipse window, above dialog appears again. If click "No" to do not save document, current window will be closed, but other eclipse window still there. Reproducible: Always Steps to Reproduce: 1.Launch Eclipse, and make sure there are some documents in it for editing. 2.Modify a document in the new eclipse window but don't save it, then create another new eclipse window from main menu "Window -> New Window" 3.Repeat step 2 until these eclipse applications are grouped on taskbar. 4.Right click the group with mouse on taskbar and then select "Close Group". 5."Save Resource" dialog will pop up, and choose "No", Bug: only the window which pops up "Save Resource" dialog is closed, left eclipse windows in the group are still there.
Problem reported by Lotus Symphony.
We need to investigate if we are receiving the SWT close events for all of the windows. PW
Eric, could you please have a look at this for 3.6.1 PW
Hmmm, this appears to be how this feature works. I tried the same scenario using WordPad and get the same behavior (each 'dirty' instance has its own dialog that must be handled before that window will close). Note that any instances that were not dirty close silently, I think this is 'by design'...they need to get you to answer discreetly in each instance of the window.
(In reply to comment #4) > Hmmm, this appears to be how this feature works. I tried the same scenario > using WordPad and get the same behavior (each 'dirty' instance has its own > dialog that must be handled before that window will close). I think the original point is that for 5 eclipse windows in the close group, we only get one dialog and one window closed. Is that correct, original opener? PW
Yes, only the window which pops up "Save Source" dialog is closed, but other windows are still here
(In reply to comment #2) > We need to investigate if we are receiving the SWT close events for all of the > windows. I have confirmed this on Windows XP with an SWT snippet. Multiple SWT.Close events are being fired.
Created attachment 178426 [details] SWT snippet demonstrating the issue This is a hacked version of Snippet99. It creates two shells using the same display (this emulates the given scenario of using 'Window->New Window' in eclipse). If you now select both the task bar items (a handy trick I learned while looking into this is that the task bar allows Ctrl-click for multi-select) and choose 'Close Group' then only the first shell gets prompted and the second doesn't. Note that multiple discreet instances of eclipse behave as expected...
Passing to SWT for further investigation...
When the SWT.Close event comes for the first Shell, the snippet opens a SWT.APPLICATION_MODAL dialog which disables all other shells. Those shells will not get SWT.Close event because they are disabled. All shells would get SWT.Close event if the dialog was SWT.PRIMARY_MODAL instead.
Created attachment 178518 [details] Patch to the EditorManager to try to make the dialog PRIMARY_MODAL Thanks Silenio. The easy proof is to simply change the dialogs in the attached SWT snippet to PRIMARY_MODAL instead of APPLICATION_MODAL and observe that the Close Group now works. The bad news is that I've tried to hack the 'Save Editor' dialog to be PRIMARY_MODAL in eclipse but if still fails the same way as it did. I'll attach a patch showing my attempt, perhaps someone more familiar with JFace can take a look...
This is deep. I've modified the snippet to use the JFace MessageDialog (with a hack to force PRIMARY_MODAL) and it works (indicating that it's not the JFace handling that's interferring). I also thought that we may be having the same issue with the prompt for the last window closing so I turned off the prompt preference...still no dice. Also, with the changes I can right-click on the taskbar and separately close each window. In this case I end up with both windows prompting to save and closing but the application does *not* shut down, it spins forever with *no* windows up... I'll attach two patches; an updated SWT/JFace snippet and a patch for the EditorManager that forces the prompt dialog to be PRIMARY_MODAL.
Created attachment 185144 [details] Updated snippet using JFace to prompt
Created attachment 185145 [details] Patch for force the EditorManager's prompt to be PRIMARY_MODAL
Created attachment 185267 [details] Hacks that make this *appear* to work This is just an interim capture of some code that at least feeds the close event to all the shells. I've produced a similar result by re-implementing Window#handleCloseEvent to make it asynchronous: rotected void handleShellCloseEvent() { if (Display.getCurrent() != null) { Display.getCurrent().asyncExec(new Runnable() { public void run() { setReturnCode(CANCEL); close(); } }); } } With no other changes this does handle getting both shells to prompt and save but doesn't exit the workbench...
Created attachment 185338 [details] A possible candidate...flushes existing events before proceeding with the first close This has two advantages...it's localized to the WorkbenchWindow code (i.e. doesn't mess with JFace's modality.
Silenio, does Eric's latest strategy seem workable? Are there potential pitfalls?
(In reply to comment #17) > Silenio, does Eric's latest strategy seem workable? Are there potential > pitfalls? I cannot see any obvious problem with the strategy. Note that I think the event loop should not be in WorkbenchWindow.close(), it should only run as part of the SWT.Close event to minimize side effects (WorkbenchWindow..handleShellCloseEvent()?) . Usually it is bad to flush events by spinning the event loop, but in this case there is going to an event loop a "couple of lines below" for the save/confirm dialog. So the biggest difference is that the events flushed by the fix will run before the shells are disabled. The user would be able to interact with those shells, but in practice there is no time for that. Unless of course, there is a ton of pending async exec runnables to run :-).
Created attachment 186091 [details] Spin the loop in 'handleShellCloseEvent' Thanks Silenio, this works fine and is a more logical place for the code...
Created attachment 186094 [details] Update patch against the maintenance stream
I've just tested this on XP in situations where the various windows have either modal or modeless dialogs up when I use the Close Group. Everything appears to work ok; shells showing a modal dialog don't 'see' the close message since they're disabled and our modeless dialogs are already set up to handle cases where the user closes the shell while they're up.
Do we need a similar fix in 4.1?
Is it true that after the fix, "Close Group" will close shells one by one and thus in the next session, we will come back with just one workbench window? Wouldn't this be unexpected? Another question: It seems to me that by spinning the event loop while handling the first close event, there will be a number of close events that are stacked, so that the following might happen: 1. User has three workbench windows (called A,B,C) 2. Selects "Close Group" 3. Close event will be sent to A 4. Event handling code spins the event loop 5. Close event will be sent to B 6. Event handling code spins the event loop 7. Close event will be sent to C 8. (For sake of argument, C has a dirty editor but A and B don't) 9. Dialog will pop up asking whether to save 10. User clicks cancel (window C will stay open) 11. Control returns to event handling code for B, window B will be closed 12. Control returns to event handling code for A, window A will be closed Since the user clicked cancel in 10., wouldn't the expectation be to not close any workbench window? How do other Windows apps behave, in similar circumstances? I'd like to play with this on a Windows XP box a bit before I give my +1.
(In reply to comment #23) > Is it true that after the fix, "Close Group" will close shells one by one and > thus in the next session, we will come back with just one workbench window? > Wouldn't this be unexpected? It might be unexpected from a user point of view, but as it looks like windows simply fires close events at all windows in the group it seems that what windows intends. Would word be an equivalent app to test? > > How do other Windows apps behave, in similar circumstances? > > I'd like to play with this on a Windows XP box a bit before I give my +1. Just a reminder that tomorrow is probably our last chance to get this in 3.6.2. PW
I've just tried a variety of mixed scenarios (same editor dirty in multiple windows and a mix if windows with some dirty, some not). The only oddity from a user's viewpoint is that even should they select 'Cancel' on the initial save dialog the other windows are still processed. This is different from selecting 'Exit' where we do special handling to only prompt once...
+1 for 3.6.2.
Fix is definitely better than the current behavior. +1.
Committed in >20110110. Applied the patch, thanks folks !
Marking as fixed...
Verified in >20110119-0834.
