Community
Participate
Working Groups
1. Open a fresh e4 workbench 2. Leave the Package Explorer activated 3. Open the Debug perspective Result: The Debug perspective contains the Package Explorer, although this should not be the case. This does not happen when another view is activated before opening the Debug perspective.
Cannot reproduce on I20100714-2048 or with my inner Eclipse.
Sorry, this bug is perhaps related to the patch from bug 319961. I am currently using CVS HEAD with that patch applied.
(In reply to comment #2) > Sorry, this bug is perhaps related to the patch from bug 319961. > I am currently using CVS HEAD with that patch applied. Please try reproducing with the patch reverted. If you cannot, please close this bug and log your findings on bug 319961. Thanks.
I can reproduce this with CVS HEAD (without the patch from bug 319961).
(In reply to comment #4) > I can reproduce this with CVS HEAD (without the patch from bug 319961). Someone else will have to test it then. I cannot reproduce this problem. 1. Delete my target workspace. 2. Launch my inner. 3. Window > Open Perspective > Debug 4. Looks good to me.
(In reply to comment #5) > 1. Delete my target workspace. > 2. Launch my inner. >> 3. Use the perspective switcher in the trim to switch to the 'Debug' perspective. > 4. Looks good to me. You need to use the perspective switcher to reproduce the problem.
Does this happen only when running with the patch from bug 319961?
(In reply to comment #7) > Does this happen only when running with the patch from bug 319961? Sorry for the spam, I should have read all the existing comments before asking.
Here's the stack from when the bogus PE is being added to the stack...the suspicious code here is that the ActivationJob is apparently trying to re-activate the PE since the dialog has gone away and it was the last active part (it doesn't know that while the dialog was up there was a perspective switch... Thread [main] (Suspended (breakpoint at line 279 in StackRenderer)) StackRenderer.createTab(MElementContainer<MUIElement>, MUIElement) line: 279 StackRenderer.childRendered(MElementContainer<MUIElement>, MUIElement) line: 334 PartRenderingEngine.createGui(MUIElement, Object, IEclipseContext) line: 427 PartRenderingEngine.createGui(MUIElement) line: 479 PartRenderingEngine$1.handleEvent(Event) line: 120 UIEventHandler.handleEvent(Event) line: 41 EventHandlerWrapper.handleEvent(Event, Permission) line: 188 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 198 EventManager.dispatchEvent(Set, EventDispatcher, int, Object) line: 227 ListenerQueue.dispatchEventSynchronous(int, Object) line: 149 EventAdminImpl.dispatchEvent(Event, boolean) line: 139 EventAdminImpl.sendEvent(Event) line: 78 EventComponent.sendEvent(Event) line: 39 EventBroker.send(String, Object) line: 73 UIEventPublisher.notifyChanged(Notification) line: 58 PlaceholderImpl(BasicNotifierImpl).eNotify(Notification) line: 380 PlaceholderImpl(UIElementImpl).setToBeRendered(boolean) line: 267 ModelServiceImpl.bringToTop(MWindow, MUIElement) line: 222 PartServiceImpl.activate(MPart) line: 394 StackRenderer(AbstractPartRenderer).activate(MPart) line: 105 StackRenderer$ActivationJob.run() line: 84 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134
Created attachment 174500 [details] Ensure that the ActivationJob only tries to activate if it's in the *currently active* perspective We likely want to make a review of all of our 'activation' policies post-release...
Committed in >20100716. Applied the patch.
I'm still not sure how/why this regression showed up though...
