Community
Participate
Working Groups
If you install the helper view displaying the current open Saveables from https://bugs.eclipse.org/bugs/attachment.cgi?id=39798, you can see that if a CompareEditor is reused, the list of open saveables is no longer correct. This can lead to incorrect prompting when closing the compare editor and may cause unsaved changes to be lost. Here are the steps to reproduce a potential data loss: - start with a workspace that has a project shared with CVS - make changes in two different files, then close all editors - synchronize changes - double-click on the first changed file, this opens the compare editor - double-click on the second changed file, this reuses the compare editor (i.e. its input is set to the compare result for the second file) - make a change in the left pane of the compare editor - close the compare editor -> You will be prompted to save changes, but with a dialog that says that the file is still open elsewhere. expected: normal prompt to save. Changes will be lost if the user believes the message in the dialog and clicks No, or if the preference to not show these kinds of dialogs is set. To set this preference, click on the checkbox, then Yes or No, and go through the steps again. This time, there will be no prompt at all and the changes will be lost.
I would like to see this fixed for RC4. Patch to follow.
Created attachment 40991 [details] patch against org.eclipse.compare
McQ, Michael, Andre, do you approve?
+1
I have some questions about the patch: 1) Can the site ever return a null life cycle listener. If it vcan, a null check is needed. 2) The lifecycle change for the new input is only fired if there was an old input. Is this the intent (i.e. is it guaranteed that the workbench will query for the saveables in the case where the oldInput was null)?
(In reply to comment #6) > 1) Can the site ever return a null life cycle listener. If it vcan, a null > check is needed. No, null will not be returned, this "service" is always there. > 2) The lifecycle change for the new input is only fired if there was an old > input. Is this the intent (i.e. is it guaranteed that the workbench will query > for the saveables in the case where the oldInput was null)? Because init() calls setInput(), this check is required. The workbench will query for the saveables after calling init(). Unless the input may be set to null during the lifetime of the compare editor, there will always be an old input when a compare editor instance is reused.
Looks like this has enough +1s without me but +1 anyway.
patch reviewed, applied, and verified for RC4
Verified using I20060512-0010.
