Community
Participate
Working Groups
1) In a non-foreground perspective, display the outline view 2) In the foreground perspective, close the outline view 3) Open a GEF Logic example editor 4) Open the outline view in the foreground 5) Click on editorpart, then click on outline's tree control. The EditorPart still has part activation, even though focus is on the outline's control. Reproduced in 0602 and RC3
Reproduced with the compilation unit editor also.
This sounds like a blocker. Keys such as DEL, Cut, CTRL+D, Ctrl+S, anything, can end up going to any other part and not the one the user just clicked on. For most workbench parts, there is no save mechanism. So a delete is a permanent change. Only editors have save.
Randy, are you able to recreate this in RC2?
> Randy, are you able to recreate this in RC2? Didn't RC2 come between 0602 and RC3?
Sorry I missed the extra 0602 dates there, I will consider your answer as a "yes, I humbly submit that whilst I did not try it on RC2, I did in fact try it on 0602 which is before RC2 so I assume it was broken there as well." <g>
Paul could you investigate please. It would be nice to know how long this has been happening as well.
So far: This problem seems to have appeared between M7 and RC1. After you show the outline, click on the part, and then click on the outline, the editor tab stays blue. The method clicked in the outline view gets selected in the outline tree, and the left bar of the editor highlights the method selected. The editor won't track the outline method selection. If you select a method that's not on the screen, you can't see it in th editor. Keys typed are still getting to the outline view, they select different methods. Some of the keystrokes still go to the editor part (like DEL, which in M7 asks if you want to deleted the outline-selected method, and in RC1 will delete characters from the last cursor position in the editor). PW
need to investigate for RC4, Doug does the last comment about delete going to the editor and not the Outline mean anything to you? to be reviewed June 21
Delete is an accelerator that goes to the global action which forwards to the active part. This has been changed for a long time in 3.1 (control's used to receive the key in 2.1) so I don't see how the outline could have gotten the DEL key in M7 unless it was the active part, or there was some glitch in swapping action delegates.
re: comment #9 You're right, in M7 the outline becomes the active part. By RC1, the editor stays the active part. PW
Oops. duh! Right, the bug wasn't in M7, so DEL key is working exactly as you would expect, i.e. it follows active part. (so what is MVM asking about??)
Reproduced on Linux GTK+. Downgrading to major, as this does not cause "crashes, loss of data, severe memory leak". I can reproduce this problem with any view. It is not particular to the Outline view. I'm going to try to track down the exact fix that caused this problem.
Here is a very rough list of files that might have been involved in this kind of a change: internal/EditorAreaHelper.java internal/EditorList.java internal/EditorManager.java internal/EditorReference.java internal/PageLayout.java internal/PartList.java internal/PartPane.java internal/PartSashContainer.java internal/PartService.java internal/PartStack.java internal/ViewFactory.java internal/ViewLayout.java internal/ViewReference.java internal/ViewStack.java internal/WorkbenchPage.java internal/WorkbenchPagePartList.java internal/WorkbenchPartReference.java internal/presentations/defaultpresentation/DefaultTabFolder.java internal/presentations/defaultpresentation/DefaultTabItem.java internal/presentations/defaultpresentation/EmptyTabFolder.java internal/presentations/defaultpresentation/NativeTabFolder.java internal/presentations/util/AbstractTabFolder.java internal/presentations/util/PresentablePartFolder.java internal/presentations/util/ProxyControl.java
If I press DEL in the outline view, and instead, a breakpoint gets deleted, that's loss of data.
Or worse, a user who quickly dismisses confirmation dialogs could delete an entire project containing unreleased code by accident.
The change appears to be a small piece of the change committed with regards to Bug 58003. It's the change in PartPane from revision 1.73 to 1.74.
Created attachment 23649 [details] Naive patch to "PartPane" Without doing any research on what kind of problems this will cause, this is a naive fix for this particular problem. It rolls back one specific part of change made on May 25, 2005. I'll take a look at what documentation might be around on why this change need to be around. There's none in code, so I'm hoping reading Bug 58003 carefully might reveal some clues.
Nick, MVM: Do either of you know why this change was done? (note: the 'naive patch' reverts the change)
Roughly, what is happening is that the view's PartPane is cached between perspectives. A flag exists, inLayout, that appears to be used as a note as to whether PartPane is actually visible in the current perspective layout. The change in question made it so that -- if the PartPane is not inLayout -- it will not respond to activation events. The problem is that hiding a view sets inLayout to false, while showing a view does not set inLayout to true. inLayout starts as true, and it seems that it can only become true again during a perspective switch. I would assume that setting the flag in showView would be another way of fixing this problem, but for some reason that doesn't seem to work. I'll have to look at this more. To get into this state, the view in question must exist in another (open) perspective. At this point, simply opening the view will have this effect.
Created attachment 23734 [details] Patch to "WorkbenchPage" I believe this is a better approach to take, and should be our approach for 3.1 RC4. This being said, I feel this change is high risk and will require significant testing. Unfortunately, we don't have any good alternatives. Stefan Xenos is on vacation, and he's the only that knows why this particular fix was required. So, reverting it naively (previous patch) may re-introduce a major bug. Similarly, we don't know if there is a specific reason why inLayout should remain false in this case (even though it seems like it should become true). The bug is significant enough that it can't be left alone.
We've managed to reach Stefan Xenos on vacation. And, while he is somewhat computer impaired at the moment, the patch to WorkbenchPage sounds like the right thing to him. He explained a bit about what the inLayout flag was originally intended to do. There were cases where activate events could arrive for a part after it had been marked for closure. This would cause the part to activate in the middle of the process of closing, and this could cause exceptions. It also hurt performance on perspective switching. We have put together a patched version of the org.eclipse.ui.workbench plug-in from N20050622-0010 (http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ui-home/gir/org.eclipse.ui.workbench_3.1.0.jar). Please try installing the patch. For those with more time, please take a moment and try to break it.
I did find one case where a view always opens as a fastview even after I have placed it back in the "regular" workbench layout, then closed it and did something that would make the view be shown. Logging bug 101335 for this, which is not likely related to this bug.
Found and logged a second bug (bug 101346) while testing this. Doug please apply this patch to head as I think both bugs are not related to this and we need a build to test more on. I will verify that this is good tomorrow at 10am, if not we can pull it out then.
I have tried the scenarios Stefan laid out. Closing all editors doesn't appear to send extraneous activation events, and switching perspectives with detached views doesn't appear to either. Of course, I have a feeling that this behaviour might vary from platform to platform.
Committed patch to CVS. Marking as FIXED.
Verified in I20050623-1200, GTK+.
