Community
Participate
Working Groups
When I click "Window->Hide Toolbar" the toolbar disappears as expected. But when I double check the editor tab to maximize or restore the editor window size, the toolbar comes back. This can't be an intentional state change becuase the menu still only offers "Window->Show Toolbar" even though the toolbar has already been made visible again. The editor I'm using is from CDT 8.2. -- Configuration Details -- Product: Eclipse 2.0.0.20130613-0530 (org.eclipse.epp.package.cpp.product) Installed Features: org.eclipse.platform 4.3.0.v20130605-2000
I have the opposite problem, when Eclipse starts there is no Toolbar. I select Window->Show Toolbar. Next time I restart Eclipse the Toolbar has disappeared again. The state of the Toolbar doesn't seem to persist correctly. This seems to be a new problem in Kepler. Eclipse Standard/SDK Version: Kepler Release Build id: 20130614-0229
I'm seeing this too. The visible state gets completely confused. I think it's made visible when a different type of editor is loaded for the first time. E.g Java editor loads and I force the toolbar to hide. XML editor loads and toolbar reappears, so I hide it again. JSP editor loads and toolbar reappears. etc. I don't have much use for the toolbar, I use the keyboard shortcuts and would rather have the additional real estate (admittedly small) that hiding the toolbar provides.
I'm also experiencing this problem. I keep disabling the toolbar, but it comes back every time I change to a different source file, or pretty do anything. It drives me absolutely crazy. I hate the toolbar. I have a keybinding I can quickly hit to make it go away again whenever it reappears, but it feels like I'm just tilting at windmills. I spend most of my life these days staring at Eclipse and I'm tired of this evil toolbar taking up all the valuable vertical space on my monitor that could be dedicated to code. Is there a workaround, CSS modification, plugin, or *anything* I can do to just make it just go away forever?
I'm experiencing this also on Linux. This is one of the more annoying bugs. I mean its absolutely vexing when you edit another type of file type that f$#@$# fisher-price-matel toolbar pops up and the state is clearly screwed up because you have to show/hide twice. If only I had a clue where in the massive source code to look I would go fix this myself.
Confirm - it annoys as hell, especially when the screen is 1024x768 (yes, I'm from stoneage). Linux Fedora 19, eclipse 4.3.
This happens with me too. Using Fedora 19 and Kepler. I hide the toolbar from Window > Hide Toolbar and at random times, the toolbar reappears. When it does reappear, the Window menu has Show Toolbar instead of Hide Toolbar. So I first show it and then hide it again. This is very annoying and should probably be an easy fix. All we need is the ability to hide the toolbar permanently. Thanks!
+1 for solving this bug. I am using kepler on Linux.
+1 linux mint, kepler, pdt
+1 Ubuntu 13.10, Kepler The weird thing is, on some days this never happens. It cannot always have to do with opening a .properties, .xml or .xhtml file for the first time or using "Quick Access". Maybe a memory issue as it often happens later in the day? In any case, I often click "Show toolbar" and "Hide toolbar" only to click in the text of a java file and the toolbar shows up again. Anyway, I am impressed by Eclipse, especially the syntactical analysis of Java Source Code. Keep up the good work!
+1 Ubuntu 14.04. I hide toolbar via menu, and it hides it. Then I switch files via Alt-Tab or close a file/editor, and the tool bar shows back up. When going back to Window menu, the menu option still shows "Show Toolbar" even though it is showing. Clicking "Show Toolbar" at this point causes the menu option to toggle back to "Hide Toolbar", and clicking again allows me to actually hide the toolbar -- although it'll show back up once i changed files/editors being viewed.
(In reply to Dolan A. from comment #10) > +1 Ubuntu 14.04. I hide toolbar via menu, and it hides it. Then I switch > files via Alt-Tab or close a file/editor, and the tool bar shows back up. > When going back to Window menu, the menu option still shows "Show Toolbar" > even though it is showing. Clicking "Show Toolbar" at this point causes the > menu option to toggle back to "Hide Toolbar", and clicking again allows me > to actually hide the toolbar -- although it'll show back up once i changed > files/editors being viewed. My previously observed behavior is not occurring anymore. Since restarting Eclipse with toolbar hidden, the toolbar remains hidden when switching tags, opening new files, etc. Other than a restart of Eclipse, I don't think any software updates have occurred. I'll report back if the problem resurfaces.
(In reply to Chris Saunders from comment #0) > When I click "Window->Hide Toolbar" the toolbar disappears as expected. But > when I double check the editor tab to maximize or restore the editor window > size, the toolbar comes back. This can't be an intentional state change > becuase the menu still only offers "Window->Show Toolbar" even though the > toolbar has already been made visible again. The editor I'm using is from > CDT 8.2. Works for me in Luna, marking as fixed. We still have an issue with the toolbar entries not allow to resurface the toolbar after a restart but that is fixed covered by Bug 432686.
(In reply to Lars Vogel from comment #12) > (In reply to Chris Saunders from comment #0) > > When I click "Window->Hide Toolbar" the toolbar disappears as expected. But > > when I double check the editor tab to maximize or restore the editor window > > size, the toolbar comes back. This can't be an intentional state change > > becuase the menu still only offers "Window->Show Toolbar" even though the > > toolbar has already been made visible again. The editor I'm using is from > > CDT 8.2. > > Works for me in Luna, marking as fixed. We still have an issue with the > toolbar entries not allow to resurface the toolbar after a restart but that > is fixed covered by Bug 432686. fwiw, I still see this issue w/ Luna SR1 (4.4.1) + CDT, so not really sure that it is fixed..
*** Bug 461240 has been marked as a duplicate of this bug. ***
I see this issue in 4.4.1 from time to time as well. It was also reproduced in 4.4.2 - bug 411724.
(In reply to Wojciech Sudol from comment #15) > It was also reproduced in 4.4.2 - bug 411724. I meant bug 461240.
OP here; if it wasn't clear from the original bug report I'm on Version: Luna Service Release 2 (4.4.2) / Build id: 20150219-0600
I've found this to be a mild nuisance for the past two years. I wish I could nuke that toolbar from orbit. Who could possibly need it?
Here is the reproduction steps from bug 461240: If I hide the toolbar with Window->Hide Toolbar and then lose and gain main window focus, the toolbar returns. Steps to reproduct: * Go to Window->Hide Toolbar * Observe the toolbar disappears, as expected * Alt-tab away * Alt-tab back * Observe the toolbar comes back. * Go to 'Window->' and note that the menu thinks the toolbar is hidden as the option is "Show Toolbar". If you select this, nothing happens. A subsequent click on "Window->" will then correctly show "Hide Toolbar" Due to other issues I'm running with: export SWT_GTK3=0 should that be important. -- Configuration Details -- Product: Eclipse 4.4.2.20150219-0708 (org.eclipse.epp.package.cpp.product) Installed Features: org.eclipse.platform 4.4.2.v20150204-1700
Reassigning to myself. I'm going to take a stab at this one.
On 4.4, this was consistently reproducible by switching editor tabs. On 4.5, this seems to occur intermittently. I can't reproduce it using the steps in comment 19, but it sometimes seems to occur when switching editor tabs.
(In reply to Stefan Xenos from comment #20) > Reassigning to myself. I'm going to take a stab at this one. Would be nice to tackle that for RC1.
Annoyingly, I can't reproduce it at all when building from source and running in the debugger. I'll try rolling the source back to a version where I could reproduce it.
I just made it happen once in the debugger and had breakpoints in WorkbenchWindow.setCoolBarVisible(...) and WorkbenchWindow.updateLayoutDataForContents. Neither one was called when the toolbar appeared.
I believe I've captured a stack trace at the moment the toolbar was made visible. This was generated in Eclipse 4.4, not the latest code. PartRenderingEngine$2.handleEvent(Event) line: 191 UIEventHandler$1.run() line: 40 UISynchronizer(Synchronizer).syncExec(Runnable) line: 187 UISynchronizer.syncExec(Runnable) line: 156 Display.syncExec(Runnable) line: 4609 E4Application$1.syncExec(Runnable) line: 218 UIEventHandler.handleEvent(Event) line: 36 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: 81 UIEventPublisher.notifyChanged(Notification) line: 59 TrimBarImpl(BasicNotifierImpl).eNotify(Notification) line: 374 TrimBarImpl(UIElementImpl).setVisible(boolean) line: 345 CleanupAddon.subscribeVisibilityChanged(Event) line: 201 GeneratedMethodAccessor27.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 606 MethodRequestor.execute() line: 55 UIEventObjectSupplier$UIEventHandler$1.run() line: 56 UISynchronizer(Synchronizer).syncExec(Runnable) line: 187 UISynchronizer.syncExec(Runnable) line: 156 Display.syncExec(Runnable) line: 4609 E4Application$1.syncExec(Runnable) line: 218 UIEventObjectSupplier$UIEventHandler.handleEvent(Event) line: 53 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: 81 UIEventPublisher.notifyChanged(Notification) line: 59 ToolBarImpl(BasicNotifierImpl).eNotify(Notification) line: 374 ToolBarImpl(UIElementImpl).setVisible(boolean) line: 345 CoolBarToTrimManager.fill(MToolBar, IContributionManager) line: 627 CoolBarToTrimManager.update(boolean) line: 549 WorkbenchWindow.updateActionBars() line: 2316 WorkbenchWindow.updateActionSets() line: 2394 WorkbenchPage$ActionSwitcher.updateActionSets(List<IActionSetDescriptor>) line: 834 WorkbenchPage$ActionSwitcher.updateActivePart(IWorkbenchPart) line: 671 WorkbenchPage$ActionSwitcher.updateTopEditor(IEditorPart) line: 698 WorkbenchPage.updateActiveEditorSources(MPart) line: 407 WorkbenchPage.updateBroughtToTop(MPart) line: 451 WorkbenchPage.access$20(WorkbenchPage, MPart) line: 450 WorkbenchPage$E4PartListener.partBroughtToTop(MPart) line: 213 PartServiceImpl$7.run() line: 305 SafeRunner.run(ISafeRunnable) line: 42 PartServiceImpl.firePartBroughtToTop(MPart) line: 302 PartServiceImpl.access$4(PartServiceImpl, MPart) line: 300 PartServiceImpl$1.handleEvent(Event) line: 97 UIEventHandler$1.run() line: 40 UISynchronizer(Synchronizer).syncExec(Runnable) line: 187 UISynchronizer.syncExec(Runnable) line: 156 Display.syncExec(Runnable) line: 4609 E4Application$1.syncExec(Runnable) line: 218 UIEventHandler.handleEvent(Event) line: 36 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: 81 UIEventPublisher.notifyChanged(Notification) line: 59 PartStackImpl(BasicNotifierImpl).eNotify(Notification) line: 374 PartStackImpl(ElementContainerImpl<T>).setSelectedElement(T) line: 171 ModelServiceImpl.showElementInWindow(MWindow, MUIElement) line: 488 ModelServiceImpl.bringToTop(MUIElement) line: 454 PartServiceImpl.delegateBringToTop(MPart) line: 705 PartServiceImpl.activate(MPart, boolean, boolean) line: 682 PartServiceImpl.activate(MPart, boolean) line: 620 ContributedPartRenderer(AbstractPartRenderer).activate(MPart) line: 106 ContributedPartRenderer$1.handleEvent(Event) line: 61 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4455 ContributedPartRenderer$2(Widget).sendEvent(Event) line: 1388 ContributedPartRenderer$2(Widget).sendEvent(int, Event, boolean) line: 1412 ContributedPartRenderer$2(Widget).sendEvent(int, Event) line: 1397 Shell.setActiveControl(Control, int) line: 1718 Shell.setActiveControl(Control) line: 1681 StyledText(Control).sendFocusEvent(int) line: 3927 StyledText(Control).gtk_event_after(long, long) line: 3169 StyledText(Widget).windowProc(long, long, long) line: 2084 StyledText(Control).windowProc(long, long, long) line: 5536 Display.windowProc(long, long, long) line: 4687 OS._gtk_widget_grab_focus(long) line: not available [native method] OS.gtk_widget_grab_focus(long) line: 14227 StyledText(Control).forceFocus(long) line: 2480 StyledText(Composite).forceFocus(long) line: 560 StyledText(Control).forceFocus() line: 2473 StyledText(Control).setFocus() line: 4364 StyledText(Composite).setFocus() line: 1443 <-- snipped some proprietary code --> CompatibilityEditor(CompatibilityPart).delegateSetFocus() line: 191 GeneratedMethodAccessor40.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 606 MethodRequestor.execute() line: 55 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 247 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 253 InjectorImpl.invoke(Object, Class<Annotation>, Object, PrimaryObjectSupplier) line: 225 ContextInjectionFactory.invoke(Object, Class<Annotation>, IEclipseContext, Object) line: 107 PartRenderingEngine.focusGui(MUIElement) line: 795 ContributedPartRenderer$2.setFocus() line: 100 CTabItem.setFocus() line: 332 CTabFolder.setFocus() line: 2555 ContributedPartRenderer$2(Control).fixFocus(Control) line: 207 ContributedPartRenderer$2(Control).setVisible(boolean) line: 4873 CTabFolder.setSelection(int) line: 3098 CTabFolder.setSelection(int, boolean) line: 3106 CTabFolder.onMouse(Event) line: 1794 CTabFolder$1.handleEvent(Event) line: 283 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4455 CTabFolder(Widget).sendEvent(Event) line: 1388 Display.runDeferredEvents() line: 3799 Display.readAndDispatch() line: 3409 PartRenderingEngine$9.run() line: 1151 Realm.runWithDefault(Realm, Runnable) line: 332 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1032 E4Workbench.createAndRunUI(MApplicationElement) line: 148 Workbench$5.run() line: 637 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 580 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 150 IDEApplication.start(IApplicationContext) line: 135 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 380 EclipseStarter.run(String[], Runnable) line: 235 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 57 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 606 Main.invokeFramework(String[], URL[]) line: 648 Main.basicRun(String[]) line: 603 Main.run(String[]) line: 1465 Main.main(String[]) line: 1438
The problematic bit of the stack trace seems to be this bit: ToolBarImpl(BasicNotifierImpl).eNotify(Notification) line: 374 ToolBarImpl(UIElementImpl).setVisible(boolean) line: 345 CoolBarToTrimManager.fill(MToolBar, IContributionManager) line: 627 CoolBarToTrimManager.update(boolean) line: 549 WorkbenchWindow.updateActionBars() line: 2316 When CoolBarToTrimManager.fill is invoked in certain circumstances, it forces the toolbar to be visible, even if it's not appropriate. The relevant code looks like this: // partial fix for bug 383569, introduced via fix for bug 402429 // If the toolbar is hidden but one of the children is not, // make both the child and the toolbar visible if (isChildVisible(item, manager)) { needUpdate |= applyOverridenVisibility(toolBarElem, item, manager); container.setVisible(true); } Presumably, the reason that this is so hard to reproduce is that it only occurs during certain specific trim manager updates. Presumably, switching between two editors that have a different set of enabled toolbars must have something to do with it. I'm off to see what bug 383569 and bug 402429 are all about. Whee!
Bug 383569 seems related but it was probably not the direct cause of this since the timing is wrong. That patch went in on Jan 10, 2015 but this was first reported in 2015.
Correction, this was reported in 2013.
I tried commenting out the container.setVisible(true) code in the last stack trace and found another case where the toolbars are made visible: It looks as though there's both a per-editor setting to control toolbar visibility and a global one. Really, they should both be true in order to enable the toolbar, but it looks as though whichever one was set last takes precident. TrimBarImpl(UIElementImpl).setVisible(boolean) line: 342 CleanupAddon.subscribeVisibilityChanged(Event) line: 201 GeneratedMethodAccessor225.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 MethodRequestor.execute() line: 56 UIEventObjectSupplier$UIEventHandler$1.run() line: 56 UISynchronizer(Synchronizer).syncExec(Runnable) line: 186 UISynchronizer.syncExec(Runnable) line: 145 Display.syncExec(Runnable) line: 4601 E4Application$1.syncExec(Runnable) line: 212 UIEventObjectSupplier$UIEventHandler.handleEvent(Event) line: 53 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: 85 UIEventPublisher.notifyChanged(Notification) line: 59 ToolBarImpl(BasicNotifierImpl).eNotify(Notification) line: 374 ToolBarImpl(UIElementImpl).setVisible(boolean) line: 345 CoolBarToTrimManager$ToolBarContributionItemExtension.setVisible(boolean) line: 76 EditorActionBars.setVisible(boolean) line: 424 EditorActionBars.setVisible(boolean, boolean) line: 453 EditorActionBars.setActive(boolean, boolean) line: 374 EditorActionBars.activate(boolean) line: 124 EditorSite(PartSite).activateActionBars(boolean) line: 593 EditorSite.activateActionBars(boolean) line: 77 WorkbenchPage$ActionSwitcher.activateContributions(IWorkbenchPart, boolean) line: 745 WorkbenchPage$ActionSwitcher.updateActivePart(IWorkbenchPart) line: 642 WorkbenchPage$ActionSwitcher.updateTopEditor(IEditorPart) line: 696 WorkbenchPage.updateActiveEditorSources(MPart) line: 405 WorkbenchPage.updateBroughtToTop(MPart) line: 449 WorkbenchPage.access$20(WorkbenchPage, MPart) line: 448 WorkbenchPage$E4PartListener.partBroughtToTop(MPart) line: 208 PartServiceImpl$7.run() line: 309 SafeRunner.run(ISafeRunnable) line: 42 PartServiceImpl.firePartBroughtToTop(MPart) line: 306 PartServiceImpl.access$4(PartServiceImpl, MPart) line: 304 PartServiceImpl$1.handleEvent(Event) line: 101 UIEventHandler$1.run() line: 40 UISynchronizer(Synchronizer).syncExec(Runnable) line: 186 UISynchronizer.syncExec(Runnable) line: 145 Display.syncExec(Runnable) line: 4601 E4Application$1.syncExec(Runnable) line: 212 UIEventHandler.handleEvent(Event) line: 36 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: 85 UIEventPublisher.notifyChanged(Notification) line: 59 PartStackImpl(BasicNotifierImpl).eNotify(Notification) line: 374 PartStackImpl(ElementContainerImpl<T>).setSelectedElement(T) line: 171 ModelServiceImpl.showElementInWindow(MWindow, MUIElement) line: 494 ModelServiceImpl.bringToTop(MUIElement) line: 458 PartServiceImpl.delegateBringToTop(MPart) line: 724 PartServiceImpl.activate(MPart, boolean, boolean) line: 701 PartServiceImpl.activate(MPart, boolean) line: 639 ContributedPartRenderer(AbstractPartRenderer).activate(MPart) line: 106 ContributedPartRenderer$1.handleEvent(Event) line: 62 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4449 ContributedPartRenderer$2(Widget).sendEvent(Event) line: 1317 ContributedPartRenderer$2(Widget).sendEvent(int, Event, boolean) line: 1341 ContributedPartRenderer$2(Widget).sendEvent(int, Event) line: 1326 Shell.setActiveControl(Control, int) line: 1727 Shell.setActiveControl(Control) line: 1690 StyledText(Control).sendFocusEvent(int) line: 3894 StyledText(Control).gtk_event_after(long, long) line: 3194 StyledText(Widget).windowProc(long, long, long) line: 1941 StyledText(Control).windowProc(long, long, long) line: 5588 Display.windowProc(long, long, long) line: 4685 OS._gtk_widget_grab_focus(long) line: not available [native method] OS.gtk_widget_grab_focus(long) line: 14269 StyledText(Control).forceFocus(long) line: 2491 StyledText(Composite).forceFocus(long) line: 571 StyledText(Control).forceFocus() line: 2484 StyledText(Control).setFocus() line: 4426 StyledText(Composite).setFocus() line: 1454 CompilationUnitEditor(AbstractTextEditor).setFocus() line: 6221 CompilationUnitEditor(StatusTextEditor).setFocus() line: 122 CompilationUnitEditor(JavaEditor).setFocus() line: 2395 CompatibilityEditor(CompatibilityPart).delegateSetFocus() line: 204 GeneratedMethodAccessor244.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 MethodRequestor.execute() line: 56 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 252 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 258 InjectorImpl.invoke(Object, Class<Annotation>, Object, PrimaryObjectSupplier) line: 229 ContextInjectionFactory.invoke(Object, Class<Annotation>, IEclipseContext, Object) line: 107 PartRenderingEngine.focusGui(MUIElement) line: 775 ContributedPartRenderer$2.setFocus() line: 101 CTabItem.setFocus() line: 332 CTabFolder.setFocus() line: 2602 ContributedPartRenderer$2(Control).fixFocus(Control) line: 214 ContributedPartRenderer$2(Control).setVisible(boolean) line: 4919 CTabFolder.setSelection(int) line: 3146 CTabFolder.setSelection(int, boolean) line: 3154 CTabFolder.onMouse(Event) line: 1841 CTabFolder$1.handleEvent(Event) line: 330 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4449 CTabFolder(Widget).sendEvent(Event) line: 1317 Display.runDeferredEvents() line: 3787 Display.readAndDispatch() line: 3398 PartRenderingEngine$4.run() line: 1127 Realm.runWithDefault(Realm, Runnable) line: 337 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1018 E4Workbench.createAndRunUI(MApplicationElement) line: 156 Workbench$5.run() line: 654 Realm.runWithDefault(Realm, Runnable) line: 337 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 598 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 150 IDEApplication.start(IApplicationContext) line: 139 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 380 EclipseStarter.run(String[], Runnable) line: 235 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 Main.invokeFramework(String[], URL[]) line: 648 Main.basicRun(String[]) line: 603 Main.run(String[]) line: 1465 Main.main(String[]) line: 1438
(In reply to Stefan Xenos from comment #26) > > Presumably, the reason that this is so hard to reproduce is that it only > occurs during certain specific trim manager updates. Presumably, switching > between two editors that have a different set of enabled toolbars must have > something to do with it. > > I'm off to see what bug 383569 and bug 402429 are all about. Whee! not sure if it helps at all, but in my experience switching focus between editors is what triggers it. Thanks for looking into this :-)
The per-editor setting in comment 29 seems to be a red herring. It's enabling individual toolbars, not the entire trim area. The strange workaround mentioned in comment 26 also seems unrelated, since the problem still occurs when the code is removed. I think I've located the real issue, though. CleanupAddon.java contains code that listens for visibility changes and whenever a UIElement is made visible, it iterates over all that UIElement's ancestors and makes them all visible as well. Removing this code fixes the bug (specifically, removing all the calls to parent.setVisible in CleanupAddon.java) The code looks bogus (since it's valid to have a visible child below an invisible ancestor -- as in the case of the main toolbar), but there seems to be lots of code depending on it. For example, minimizing and restoring windows starts producing screen cheese when I remove this code. Looking into the causes of the screen cheese next.
> not sure if it helps at all, but in my experience switching focus > between editors is what triggers it. Thanks for looking into this :-) Yep. Seems to occur most reliably when switching between two editors that use a different set of toolbar contributions.
New Gerrit change created: https://git.eclipse.org/r/46964
I've attached a fix here: https://git.eclipse.org/r/#/c/46964/ The code in CleanupAction automatically makes a parent element visible when one of its children becomes visible. It appears that this was intended to make make SashContainer and PartStack work correctly, but it's not appropriate for toolbars or unknown element types. My fix adds some instanceof checks so that this recursive visibility code only runs on element types where this sort of thing is known to be safe and appropriate. Note that there is some risk to this change since it's hard to tell if there is any code relying on these visibility side-effects. I tested switching editors and perspectives while detached views were open, drag and drop, and minimized views... and it seems to be working okay, but this is the sort of thing that should really needs to soak for a bit. I'll let folks more in tune with the release cycle decide if this should go into 4.5 or early 4.6. It's possible that this is not a complete fix. Since the visibility state of the toolbar is public and unprotected, it's possible that there are still other code paths that toggle it inappropriately. In particular, the code in CoolBarToTrimManager.fill still worries me.
Note that I never found a completely reliable way to reproduce it. I tested this by switching between different types of editors and perspectives repeatedly with the toolbar disabled until I hit the new "shouldReactToChildVisibilityChanges" method with a toolbar parent and visible child. (I used the debugger to determine that it got hit). That corner case causes the toolbar to reappear without my patch and does not cause it to reappear with the patch.
New Gerrit change created: https://git.eclipse.org/r/46966
Promoted to P1 due to the number of votes.
(In reply to Sergey Prigogin from comment #37) > Promoted to P1 due to the number of votes. If you OK with the change, please set the review flag in this bug report
For those of you having difficulty reproducing this: I believe it may be much easier to reproduce in the Resource perspective when switching between java editors, text editors, and PDE editors. In the java perspective, the perspective itself enables a lot of the same action contributions as the editors so you don't get much toolbar churn. In the Resource perspective, there are fewer action sets requested by the perspective so you'll hit this case much more often.
With the tip of using the Resource perspective I was finally able to reproduce the refacing toolbar. With Stefans patch I cannot reproduce it anymore. I also triggered the CleanupAddon several times via the UI and the behavior seems good to me. +1 from me.
Gerrit change https://git.eclipse.org/r/46964 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=9698e93eff000d84c2c584b1dbaad3344af410a2
.
Thanks you, Stefan, and all who reviewed the patch.
I did not see yet the toolbar reappear in 4.5.0.I20150511-2130.
Boom!
