Community
Participate
Working Groups
In a customized Java Debug perspective I made a Java search for references, but no result view appeared. Explicit Window > Show View doesn't produce any visible result either. I had one part stack minimized, but the problem persists after restoring it. No indication of anything else being minimized is shown. This seems to affect a certain group of views that would go into the same part stack: - Search - Errors - Tasks - Progress - ... Not affected: - views belonging to the debug perspective, e.g., Expressions - views belonging to another part stack, e.g., Navigator Reset perspective to defaults does fix the issue. Next I'll save my customized perspective and if it happens again, I'll try if resetting to the saved state also helps.
I think I observed the same problem in version 4.5.1 on Windows 7. While working in the Java Debug perspective I wanted to open the Call Hierarchy view. I tried the following without success: - the command Open Call Hierarchy in the Java editor context menu - the keyboard shortcut Ctrl+Alt+H - Window > Show View (the Call Hierarchy view is grayed out) After resetting the perspective I have been able to open the view.
*** This bug has been marked as a duplicate of bug 471782 ***
Re-opening as I'm seeing this bug still in I20151222-0800 (despite the fix for bug 471782). Comparing versions of workbench.xmi in the broken state vs. good states, I see that the following element is missing in the broken state: <children xsi:type="menu:ToolControl" xmi:id="_b_5N4KzFEeWJePGVwhE9UQ" elementId="org.eclipse.debug.internal.ui.ConsoleFolderView(IDEWindow).(org.eclipse.debug.ui.DebugPerspective)" contributionURI="bundleclass://org.eclipse.e4.ui.workbench.addons.swt/org.eclipse.e4.ui.workbench.addons.minmax.TrimStack"> <tags>TrimStack</tags> <tags>Draggable</tags> </children> Indeed in the debug perspective it's the PartStack "ConsoleFolderView" that contains all the invisible views. I assume, the breakage has happened long ago, but I'd suggest that attempts to show a view in a PartStack with missing TrimStack should re-create the missing stack. BTW, in the same broken state, the Java perspective was unable to show the Outline view. Adding a snippet like the above succeeded in repairing this situation, too.
Can we formulate an invariant for consistent state in workbench.xml? It seems that each (hidden?) PartStack should always have a TrimStack associated, right? To fix this I see two options: (1) repairing workbench.xmi when it is definitely broken (2) raise an exception when it is changed in a way that violates an invariant. Not being able to open views is a really bad situation to be in.
(In reply to Stephan Herrmann from comment #3) > Re-opening as I'm seeing this bug still in I20151222-0800 (despite the fix > for bug 471782). I assume that's on 4.6/Neon? The backported fix wasn't committed for 4.5.2 until January 7. (In reply to Stephan Herrmann from comment #4) > Can we formulate an invariant for consistent state in workbench.xml? It > seems that each (hidden?) PartStack should always have a TrimStack > associated, right? I don't think that's true. The 3.x Workbench code creates a TrimStack to host a minimized stack, but a PartStack could be hidden by 4.x code for arbitrary reasons. Can you attach your workbench.xmi?
Created attachment 259748 [details] workbench.xmi in the bad state Here's a workbench.xmi that defines two debug perspectives: - one with elementId "org.eclipse.debug.ui.DebugPerspective.Debug Dual", which is broken - one with elementId "org.eclipse.debug.ui.DebugPerspective", which works OK In the broken "Debug Dual" perspective, the following views cannot be displayed, although the corresponding action (e.g., search) is performed OK (as can be seen by activity in the progress bar): - Search - Call Hierarchy - Task List (mylyn) (I even need to enter credentials for secure storage, which proves that mylyn is already accessing my task repositories, still nothing is shown) - Outline - Error Log - History - Registers (debug) - MonitorView (Object Teams) Except for the mylyn Task List I see all these views mentioned as children of these two part stacks: <children xsi:type="basic:PartStack" xmi:id="_zBa6nXXaEeW4XdW1FOYCzg" elementId="org.eclipse.debug.internal.ui.OutlineFolderView" visible="false" containerData="2500" selectedElement="_zBa6nnXaEeW4XdW1FOYCzg"> ... <children xsi:type="basic:PartStack" xmi:id="_zBa6oHXaEeW4XdW1FOYCzg" elementId="PartStack@fdab88" visible="false" containerData="2659" selectedElement="_zBa6pXXaEeW4XdW1FOYCzg"> ... Inside <trimBars>..</trimBars>, OutlineFolderView has a TrimStack for DebugPerspective, but none for "DebugPerspective.Debug Dual". PartStack@fdab88 doesn't have any TrimStack associated to it. HTH
(In reply to Brian de Alwis from comment #5) > (In reply to Stephan Herrmann from comment #3) > > Re-opening as I'm seeing this bug still in I20151222-0800 (despite the fix > > for bug 471782). > > I assume that's on 4.6/Neon? The backported fix wasn't committed for 4.5.2 > until January 7. I20151222-0800 *is* a Neon build :) Plus I'm not speaking about views remaining blank (like bug 471782), but remaining completely invisible, not a single pixel indicating their existence. > Can you attach your workbench.xmi? done, although in this particular case it was from a 4.5.1 setup. I'll keep you posted when I see it again on Neon.
Created attachment 260902 [details] one more broken workbench.xmi Once more, now in Build id: I20160317-0200. Trying to look into the Console View but it is nowhere to be found.
(In reply to Stephan Herrmann from comment #8) > Created attachment 260902 [details] > one more broken workbench.xmi > > Once more, now in Build id: I20160317-0200. > > Trying to look into the Console View but it is nowhere to be found. I was in perspective "Debug Dual" Seeing the "needinfo" keyword: please specify what info you need!
*** Bug 496813 has been marked as a duplicate of this bug. ***
This bug has keyword "needinfo" set. Meanwhile it's the reporters who need additional info: I have no idea what additional info we should supply after having provided a broken workbench.xmi and having analysed in which regard this file is broken.
Created attachment 263041 [details] workbench.xmi for broken views This is a broken workbench for bug #496813. Not sure, if this is really a duplicate. Is workbench.xmi the only file, that is changed, if I reset perspective is invoked?
I found this in my workbench.xmi (Java perspective): ############################### <children xsi:type="basic:PartStack" xmi:id="_7GJIVjlbEeaKteDjMjLumA" elementId="PartStack@564b8049" visible="false" containerData="2443" selectedElement="_7GJIVzlbEeaKteDjMjLumA"> <tags>Minimized</tags> <children xsi:type="advanced:Placeholder" xmi:id="_7GJIVzlbEeaKteDjMjLumA" elementId="org.eclipse.ui.views.ContentOutline" ref="_7GJKWzlbEeaKteDjMjLumA"/> </children> ############################### Once I removed these lines and restarted Eclipse I was able to restore my Outline view again. I had to show it, drag it and minimize it to a quick view. It remains intact even after an eclipse restart. Somehow these lines keep the view from functioning.
Removing 'needinfo' keyword since no question for additional info was asked.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Although I haven't seen this problem in a while, I do request that someone inspects the various broken workbench.xmi files that have been attached and comments on whether or not anything has been changed in the code to prevent this from happening again. Reporters have spent significant time in providing all information they could. This information should be looked at, at the very least.
(In reply to Stephan Herrmann from comment #16) > Although I haven't seen this problem in a while, ... As if the tool was listening: just now it happened again in Eclipse 2020-03.
