Community
Participate
Working Groups
4.3 RC4 Make an editor dirty (change some content) and then drag it outside the workbench window to create a detached editor shell. Create a new workbench window, and then drag the detached editor's tab into the new workbench window. Expected: Either drop cursor becomes "cannot drop" and dropping does nothing, or drop works and the dirty editor ends up in the new window. Was: Editor is closed without any questions, and my content changes are lost.
(In reply to comment #0) > 4.3 RC4 > > Make an editor dirty (change some content) and then drag it outside the > workbench window to create a detached editor shell. Create a new workbench > window, and then drag the detached editor's tab into the new workbench > window. It's not even necessary to create a new workbench window - just dragging the editor's tab outside its window is enough. Also happens on Linux. Loss of data is considered 'critical'.
For me the drag 'out' seems to work ok, the editor appears in the new DW and is still dirty and dragging it back also seems to work. Here's what I'm doing: 1) Open editor and make it dirty 2) Drag Editor out to DW. It shows dirty and trying to close it gets you a prompt. 3) Drag the editor back into the original window. It shows dirty and trying to close it will get you a prompt. The only way we've identified here to not get the prompt is to have dirty editors / views in a DW that is *not* in the current perspective. In this case it isn't included in the search for the 'dirty' elements and so isn't prompted for saving. Is it possible that this is what's happening here ? BTW, I can't drop the editor back into anything except the original top level window.
(In reply to comment #2) Yes, these steps work fine. But if you modify step 3 and drop the detached editor's tab anywhere outside the originating workbench window and outside the detached window, then the editor is lost. > The only way we've identified here to not get the prompt is to have dirty > editors / views in a DW that is *not* in the current perspective. In this > case it isn't included in the search for the 'dirty' elements and so isn't > prompted for saving. Is it possible that this is what's happening here ? No, that's a separate bug (that an editor outside the shared editor area becomes part of the perspective. It's also no longer possible to split the editor area and retain all editors when switching perspectives.) > BTW, I can't drop the editor back into anything except the original top > level window. I also don't get a drop marks inside the second workbench window, but I still see the green rectangle and the hand cursor (which used to be a nice "window" cursor in 3.8), and I can drop the tab anywhere I want. After the drop, it disappears. BTW: The same happens for detached views.
Yoiks !! Yes, this is bad...thanks for the clarification Markus.
This is a problem in the DnD code for detached windows; it also happens when ever the contents of the original DW go empty (either by dragging the last stack out of it or the last tab of the only stack in the DW. It's likely another issue with the CleanupAddon's asynch code...
ModelServiceImpl:879 creates a hierarchy of windows. So when you do the first detach you have Win1. When you do the second detach you create Win2 as the 'child' (EMF feature 'windows') of Win1. Then the clean up addon destroys Win1 but before it does it needs to kill its 'children' so Win2 goes down too. I'm not sure of the optimal solution but we either stop creating the windows hierarchy or have the cleanup addon reparent Win2 to the parent of Win1 before it kills Win1.
GIT Commit id (for master): http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d1cca9237e6500daf70829dc0089d3a9bc2cab61 This turned out to be a defect in the 'detach' method in the model service. Under these specific conditions it was actually adding the new window as a child of the initial *detached* window. That meant that when the 'old' (now empty) DW was torn down it caused the new shell to be disposed as well. The new code is greatly simplified using these rules: 1) If the element being detached is currently in a perspective the new DW is added to that persp's list of windows. 2) If it's not in a perspective then it's added to the *top level* window. It also includes a minor fix to the CleanupAddon found during debugging... Thanks Sopot !
(In reply to comment #7) > GIT Commit id (for master): > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=d1cca9237e6500daf70829dc0089d3a9bc2cab61 > > This turned out to be a defect in the 'detach' method in the model service. > Under these specific conditions it was actually adding the new window as a > child of the initial *detached* window. That meant that when the 'old' (now > empty) DW was torn down it caused the new shell to be disposed as well. > > The new code is greatly simplified using these rules: > > 1) If the element being detached is currently in a perspective the new DW is > added to that persp's list of windows. > > 2) If it's not in a perspective then it's added to the *top level* window. > > It also includes a minor fix to the CleanupAddon found during debugging... > > Thanks Sopot ! Verified that it fixes the problem. Increased the bundle version of 'org.eclipse.e4.ui.workbench.addons.swt' with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=074d91ff7c0a5ab4dbf3ac99256ae149615c2645 Reopening, as this bug is targeted for 4.3.1 but the fix only went into 'master' so far.
I'll mark this fixed in M1 and clone for 4.3.1 PW
.
