Community
Participate
Working Groups
I20050509-2010 * exit the workbench from the debug perspective with the "show logical structures" toggle on * restart the workbench > the toggle is off and remains off even after the start of a debug session
This is a problem for all toggles in debug views. When the view is disposed the toolbar manager no longer provides contribution items (i.e. it's an empty collection).
Nick, we used to persist the state of toggle buttons in debug views whe the view was disposed by going thru the toolbar manager's items and noting the state of contribution items with the "toggle" style. However, when a view is now disposed the toolbar manager claims to have no contribution items. Do you know when this changed? and if it was intentional? We chose to use the dispose callback rather than "saveMemento" as it also worked when the user closed/opened the view rather than just on workspace shutdown.
There have been various changes in the past couple of milestones to make workbench lifecycle more consistent. It's possible that the contribution managers are now getting disposed before the part. Stefan, do you know if this was intentional?
This represents a regression in the behavior of the abstract debug view which is API. Is there any more insight on this one?
Moving to Stefan for comment.
I think this can be fixed by moving the call to super.doDisposePart to the top of the method in ViewReference.doDisposePart. Still need to investigate how things worked in 3.0.
At this point we believe this is a regression in part lifecycle, and needs to be addressed for 3.1.
After some investigation, the event order is the same for 3.0 and 3.1. In both cases, the order of destruction for views is: 1. view widget disposed 2. contribution item widget disposed 3. IContributionItem.dispose 4. IWorkbenchPart.dispose The difference is that Eclipse 3.0 never removed the disposed contribution items (which can prevent the items from being GC'd), whereas Eclipse 3.1 removes them when they are disposed. This appears to have been caused by the patch to bug 19336. At this point, the safest fix may be to roll back the ViewPane changes made in bug 19336... but in the long-run it may make sense to dispose the view's site after the view itself, and to empty toolbar manager with the site (however, the latter solution is too high rick for 3.1). I've written a regression test for the contribution item disposal order.
Nick: what is the intended semantics of IContributionItem.dispose()? I can think of two possibilities: 1. It must be the last method called on the contribution item. After calling dispose(), it is a bug to continue using the contribution item. 2. It is a request to dispose the associated SWT widgets, however it is valid to continue using the contribution item after it has been disposed. If the answer is 1, then the 3.0 disposal order was wrong. In this case, I can see two possibilities: a) Change the view disposal order to (widget disposed, view disposed, contribution item widgets disposed, contribution items disposed). In this case we guarantee that the contribution items are still valid when the view is disposed. b) Leave the view disposal order as (widget disposed, contribution item widgets disposed, contribution items disposed, view disposed), but we close this PR as INVALID. In this case, we guarantee that the view / contribution item lifecycle is unchanged, and indicate that the 3.0 behavior of returning a disposed contribution item was a bug. For the moment, I will attach a patch and regression tests that makes everything behave like 3.0 (ie: I will assume interpretation 2 for IContributionItem.dispose). This is definitely the safest approach, but the more I think about it, the more I suspect it's a bug.
Created attachment 22490 [details] Adds the toolbar contribution item lifecycle to the view lifecycle test Includes regression tests for this bug (assumes the 3.0 behavior was correct).
Created attachment 22491 [details] Fix for this bug (for inspection) Fixes this regression. Brings back the 3.0 behavior, right or wrong. (Note: this patch preserves the fix to bug 19336 -- it should not create any leaks).
The intent is (1). IContributionItem.dispose() is called by the parent contribution manager when the manager is being disposed. The intent is to free any listeners, etc. allocated by the contribution item, not to dispose the widgets. The widgets can be disposed an recreated repeatedly during the life of the contribution item (though state typically gets lost when this is done).
In that case it's a bug to be returning disposed contribution items. IMHO we should bring back the 3.0 bug for the time being and investigate a real fix for 3.2.
That makes sense to me.
Fixed in head. Filed bug 98754 to record the fact that this "fix" may actually be a bug.
Verified that the scenario outlined in the description now works. I20050610-0010, GTK+.
