Bugzilla – Full Text Bug Listing
| Summary: | Shared area grows in number of part stacks after having moved views inside it | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> |
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> |
| Status: | VERIFIED FIXED | QA Contact: | Remy Suen <remy.suen> |
| Severity: | major | ||
| Priority: | P3 | CC: | emoffatt, Mike_Wilson, the.ubik |
| Version: | 1.0 | Flags: | emoffatt:
pmc_approved?
emoffatt: review+ |
| Target Milestone: | 4.1 RC4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Remy Suen
Created attachment 197625 [details]
Patch to explicitly remove empty stacks in the MArea on reset
The CleanupAddon is also correctly removing the sashes from the MArea if it can, reverting back to a single (possibly empty) MPartStack if it can.
Remy, can you check the patch out ? Since the event loop has to spin I tested the state of the MArea by adding a breakpoint and examining the child list for the MArea on a separate reset... This also seems to fix bug 348625... Created attachment 197630 [details]
Screenshot depicting the problem in question.
I was able to get the system into this state. That stack seems to be the stack of the 'Problems' view as it still has a view menu on it (and when clicked it shows the view menu of the 'Problems' view).
This includes drawing multiple views into the shared area and stacking them with editors and then resetting.
Perhaps the View Menu (which I can't see in the screen cap) is a manifestation of bug 348585 ? I couldn't reproduce this but don't doubt that its there ,the question may be if it is worse without the patch ? Created attachment 197659 [details]
Screenshot depicting the problem in question.
This image will illustrate how to reproduce the problem. It's likely that the shape does not need to be this complex to induce the bug but anyway...
Until we understand the problems described by comment 4 and comment 6, I am not comfortable with going ahead with this patch. (In reply to comment #6) > It's likely that the > shape does not need to be this complex to induce the bug but anyway... I was able to get the problem by making the shared area have three stacks stacked horizontally going editor, 'Outline' view, second editor and then resetting the perspective. Created attachment 197660 [details]
ModelServiceImpl patch v2
The part stack is removed from the model but its control doesn't actually get destroyed (or reparented to the limbo shell for that matter) so it just hangs around on the workbench window. If the part stack is first unrendered and then removed from the application model then there won't be a tab folder floating around on the shell.
I've opened Bug 348885 to track the fact that this pattern should be unnecessary... Remy, while it's not as bad as I feared the manifestation of bug 348625 is a door through which you can get the UI in trouble; once you're in the state defined by 348625's state then maximize the empty editor stack (seems OK) then minimize the Outline view's stack (ooops!! no EA any more and nothing in the trim...). A reset at this point brings back the EA but it only has one button (restore) so you have to maximize / unmaximize a view in order to get everything back into what *appears* to be a normal state... I do understand your point that we're messing with our own safety net here so we have to be even more careful but I think this is worth doing... Since the stacks now get unrendered properly through the rendering engine, their controls should be disposed and we should not be leaking anything (or drawing anything random on the screen). As we are only removing stacks that have zero children, this change should be safe in that we will not be inadvertently destroying any parts in between a reset request. Eric, please work with Paul to update the readme with an entry asking the user to use 'Reset Perspective' or 'Window > New Window' to get back in a clean state without having to revert to restarting Eclipse. Committed in >20110609. Applied Remy's patch... *** Bug 348945 has been marked as a duplicate of this bug. *** Created attachment 197723 [details] EModelService patch v3 1. Open two editors. 2. DND and split the area. 3. Ctrl+Shift+W to close them. 4. Now the area will still have a part sash container and two part stacks, one that's being rendered and one that isn't. The attachment reverts the changes suggested by bug 197660 as the clean-up processing should now unwind the structure correctly, destroying rendered part stacks that have no children. It is theoretically possible that the part stack in question may be the last one in the area but is not being rendered in which case it would return the wrong value even though we want it to return 'true' because it is indeed the last stack in the area. I'm not sure how realistic this scenario is but I thought I would bring it up. Reopening as the original fix was a workaround and the editor stack calculation code is the one that is wrong. Agreed. Original fix just guaranteed we weren't in the bad state at the end. This one actually fixes the issue that got us in the bad state. This new patch is much better, the original 'empty' stacks were a manifestation of not identifying the lastEditorStack correctly. Committed in >20110609. Applied the 'v3' patch. It's been code reviewed and has had PMC (re)approval. Marking as (re)FIXED. Verified in I20110613-2055. Created attachment 223661 [details]
Empty stack persists
I am still seeing this in Eclipse Platform Version: 4.2.1.v20120814-120134-9JF7BHVGFyMveli1uX6aTH0q-eAap6PAgOP5mO Build id: M20120914-1800 See the attachment I posted |