Bugzilla – Full Text Bug Listing
| Summary: | View tool bar is disposed prematurely even though it's still up in another perspective | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> | ||||||||||
| Component: | UI | Assignee: | Remy Suen <remy.suen> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | Eric Moffatt <emoffatt> | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | Olivier_Thomann, pwebster | ||||||||||
| Version: | 1.0 | ||||||||||||
| Target Milestone: | 4.1 M7 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Remy Suen
1. Ctrl+3 > JUnit 2. Click the history dropdown once to force it to be created and shown. 3. Window > Open Perspective > Debug 4. Ctrl+3 > JUnit 5. Window > Open Perspective > Java 6. Window > Reset Perspective... > Yes 7. Ctrl+3 > JUnit 8. Click the dropdown again. The NPE will be thrown. The tool item shouldn't have been destroyed when the perspective was reset since the view itself was still open in the 'Debug' perspective. Thread [main] (Suspended (breakpoint at line 133 in HistoryDropDownAction$HistoryMenuCreator)) HistoryDropDownAction$HistoryMenuCreator.dispose() line: 133 ActionContributionItem.handleWidgetDispose(Event) line: 474 ActionContributionItem.access$1(ActionContributionItem, Event) line: 466 ActionContributionItem$6.handleEvent(Event) line: 447 EventTable.sendEvent(Event) line: 84 ToolItem(Widget).sendEvent(Event) line: 1053 ToolItem(Widget).sendEvent(int, Event, boolean) line: 1077 ToolItem(Widget).sendEvent(int) line: 1058 ToolItem(Widget).release(boolean) line: 808 ToolBar.releaseChildren(boolean) line: 807 ToolBar(Widget).release(boolean) line: 811 CTabFolder(Composite).releaseChildren(boolean) line: 873 CTabFolder(Widget).release(boolean) line: 811 CTabFolder(Widget).dispose() line: 446 StackRenderer(SWTPartRenderer).disposeWidget(MUIElement) line: 137 PartRenderingEngine.safeRemoveGui(MUIElement) line: 664 PartRenderingEngine.access$1(PartRenderingEngine, MUIElement) line: 615 PartRenderingEngine$5.run() line: 610 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.removeGui(MUIElement) line: 595 PartRenderingEngine.safeRemoveGui(MUIElement) line: 648 PartRenderingEngine.access$1(PartRenderingEngine, MUIElement) line: 615 PartRenderingEngine$5.run() line: 610 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.removeGui(MUIElement) line: 595 PartRenderingEngine$1.handleEvent(Event) line: 136 UIEventHandler.handleEvent(Event) line: 41 EventHandlerWrapper.handleEvent(Event, Permission) line: 197 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 197 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 230 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 148 EventAdminImpl.dispatchEvent(Event, boolean) line: 135 EventAdminImpl.sendEvent(Event) line: 78 EventComponent.sendEvent(Event) line: 39 EventBroker.send(String, Object) line: 73 UIEventPublisher.notifyChanged(Notification) line: 58 PartSashContainerImpl(BasicNotifierImpl).eNotify(Notification) line: 380 PartSashContainerImpl(UIElementImpl).setToBeRendered(boolean) line: 288 WorkbenchPage.resetPerspective() line: 2543 Alternate steps to reproduce the problem: 1. Ctrl+3 > JUnit 2. Click the history dropdown once to force it to be created and shown. 3. Window > Open Perspective > Debug 4. Ctrl+3 > JUnit 5. Window > Open Perspective > Java 6. Close the 'JUnit' view. 7. Close the 'Package Explorer' view. 8. Ctrl+3 > JUnit 9. Click the dropdown again. The NPE will be thrown. *** Bug 339743 has been marked as a duplicate of this bug. *** (In reply to comment #0) > I somehow got into a state where clicking the dropdown for the 'JUnit' view's > history would just keep throwing NPEs. Closing all instances of the view in all > perspectives and reopening the view resolved the problem. If this workaround doesn't work, make sure you close all instances of that view in all perspectives as well as "destroying" any stack it was under by closing all of its sibling parts. Created attachment 191024 [details]
ToolBar rendering patch v1
Reparent the control so that it doesn't get disposed when the tab folder is disposed.
Created attachment 192666 [details]
ToolBar rendering patch v2
Arbitrarily reparenting the control will mean it may never get disposed. This new patch changes more code in other areas and tries to keep a consistent state by using the visibility of the element to prevent controls from being disposed randomly.
I don't really like this approach because the renderer's disposeWidget(MUIElement) method is still not actually disposing the widget.
Created attachment 192735 [details]
ToolBar rendering patch v3
This patch is less disruptive and forces all changes to be in the ContributedPartRenderer and StackRenderer instead.
The CPR will handle the disposal of the part's toolbar and menus (not ideal in my opinion but does ensure that they don't go away unless the part goes away). The SR's sole purpose is for toggling the visibility states of the toolbars and will not force the toolbars to be unrendered.
Created attachment 192736 [details]
ToolBar rendering patch v3
It seems I missed the StackRenderer from my patch.
(In reply to comment #8) > Created attachment 192736 [details] > ToolBar rendering patch v3 Patch released to CVS HEAD. Verified with I20110426-0200 on Windows XP. |