Community
Participate
Working Groups
Created attachment 215779 [details] Partial transition between JUnit and Variables view Build Id: N20120421-2021 1. I have JUnit and Variables (from debug) views in the same stack - this stack is in a detached window, but I don't think this matters 2. I'm running tests in debug perspective 3. JUnit view is active and shows progress 4. Tests stop at a breakpoint 5. JUnit view becomes empty (white - whatever white means in 4.2) 6. I click into the view Effect: the variables view is activated and now renders. The state (5) is broken, that stack doesn't show any information. I'm not sure if this is a problem in Platform UI or Debug UI. I've seen empty views quite frequently, which need to be clicked into to force rendering. However, this case is even worse, as the stack still shows the JUnit view as active. I just verified that Build I20120514-1900 basically has the same problem.
Created attachment 215781 [details] activation mess From various degrees during the switch between JUnit and Variables views this looks most interesting: Has Variables view been "activated" as a fast view? The picture is the result of starting with a smaller window and then in the broken state enlarge the window, which reveals that the JUnit view is still working *below* a broken Variables view. I also had the intermediate state, where the "Name" & "Value" header appeared as content of the JUnit view without any resizing.
Not a blocker, but not normal severity either, makes 4.2 look unprofessional.
This is likely caused by a difference in when (or if?) we send various partVisible, partHidden or partBroughtToTop events. The magic 'white' occurs most often for me on the Variables view but my suspicion is that the affected views all try to limit there impact when they're not visible tot he user..
Stephan, we're looking into this one right now...It's very strange and is likely the root cause of some other oddities we're seeing. The only common bit is that it only seems to manifest when a breakpoint is hit... We've been using the Variables view case instead of this scenario but are confidant that they're both the same issue (i.e. the Variables Composite is showing even though it's not he topmost tab and doesn't resize when the stack does...
Sound reasonable. Good luck!
*** Bug 378201 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Stephan, we're looking into this one right now...It's very strange and is > likely the root cause of some other oddities we're seeing. > Another way to reproduce this is to run the JDT debug test suite. I noticed it the other day, if you give focus to the target workspace that is opened during the tests you can see all of the debug views open as Stephan describes. To run the test suite grab org.eclipse.jdt.debug.tests and run the shared launch configuration in the project. > The only common bit is that it only seems to manifest when a breakpoint is > hit... Perhaps this is related to how Debug switches perspectives. See org.eclipse.debug.internal.ui.launchConfigurations.PerspectiveManager for how we switch perspectives and org.eclipse.debug.internal.ui.contexts.LaunchSuspendTrigger for where we call to cause the switch.
OK, we've found this. It's an interaction between the CTabFolder and the rendering engine. The rendering engine calls 'setVisible(true)' on an element's composite in safeCreateGui, if the element is not the top element in the stack it magically gets put on top of the real selected tab's control. patch coming...
Created attachment 216289 [details] Specifically inhibit making MPlaceholder composites visible This is safe in that we don't ever set these composites to visible==false (but the CTF code does). Checks should include ensuring that calling 'showView(blah, null, IWorkbenchPage.CREATE)' doesn't have issues and that switching to new views using the QuickAccess works both when the view hasn't been rendered yet and when it has...
We should check this but it does fix a highly visible defect so I'd really like to get it into RC3..
(In reply to comment #9) > Created attachment 216289 [details] > Specifically inhibit making MPlaceholder composites visible > That's much better than it was. But in one startup case, I get the Breakpoints view with empty content. 1. Start up eclipse in the java perspective. 2. launch a debug session with F11 3. it'll hit a breakpoint and auto-switch to the Debug perspective. The Breakpoints view is visible, but empty. Clicking on the tab fills it in. After that, repeating the same scenario leads to a Breakpoints view that looks correct. PW
This effect exists but is not related to the fix in the patch; yo get the identical effect whether or not the patch is applied...
I opened bug 380716 for this case. I think the fix is good for RC3. PW
+1 for RC3.
This might just be my paranoia, but this patch adds an extra check that is unrelated to the fix: if (!control.isVisible()) control.setVisible() Now this should be just an extra free check, except the implementation of control.isVisible() looks like this: checkWidget (); if (OS.IsWindowVisible (handle)) return true; return getVisible () && parent.isVisible (); Which looks slightly different from the sanity checks in Control.setVisible: if (!getDrawing()) { if (((state & HIDDEN) == 0) == visible) return; } else { int bits = OS.GetWindowLong (handle, OS.GWL_STYLE); if (((bits & OS.WS_VISIBLE) != 0) == visible) return; } Note that Control.isVisible also checks visibility of the parent, while Control.setVisible does not. So it looks to me like this extra check might in some cases cause changes in behaviour, and/or less SWT.Show events to occur. Looking at other calls to Control.setVisible(true) in the UI, very rarely do we insert this extra check. So my question is, is there a reason we think this extra check is worth adding in RC3? And why would we just add it here and not around all calls to Control.setVisible?
I'll gladly remove the check to remove the possibility if you want...
Eric and I discussed and decided to release without the extra check. What he was thinking of was Control.getVisible (not recursive to parent) rather than isVisible (recursive). There are important cases where these two methods will have different answers, such as minimized views, so there is a real risk of unexpected changes here. However Control.setVisible does the identical set of checks to Control.getVisible so the extra call is truly not needed in that case.
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=40f322457790733e83a03de9ccc2ca1abc0abef7
I'm looking forward to RC3. Thanks to you all!
Verified in I20120525-1900.
