Community
Participate
Working Groups
org.eclipse.ui.test testBug288765 failed on windows in the build I20181121-1800 junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:55) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertTrue(Assert.java:31) at junit.framework.TestCase.assertTrue(TestCase.java:201) at org.eclipse.ui.tests.statushandlers.StatusDialogManagerTest.testBug288765(StatusDialogManagerTest.java:950)
I am not able to reproduce the test failure on local windows machine.
The assertion that fails: assertTrue(newSize.height > sizeY);
I found the reason for this failure. Will provide a fix soon.
New Gerrit change created: https://git.eclipse.org/r/156441
The test checks if a details area with few text is smaller than a details area with much text or from another perspective if the details when opened is resized depending on the available content. Additional the dialog ensures the details area is not moved outside the available screen space. The dialog itself is never moved automatically. If there is not much space left below the dialog the details area cannot made larger than the minimum size and the test fails. This is the simplified explanation. Reality is a little more complicated which make the failure more random. The primary reason why it fails only random is that the failure is dependent on the dialog position. As explained the assert(newSize.height > sizeY) can fail if the dialog is to close to the bottom of the screen. The dialog position depends on the parent window position which (for automated tests where the workbench is not maximized) depends on the window manager. For Windows the position is in this context unpredictable and as result the test can succeed or fail. What make this hard to reproduce is that the screen resolution has a major influence. I was not able to reproduce it with resolution 1920x1200 without manual intervention/debugging. I was able to reproduce it (again random) with 1280x1024 or 1024x768. (the later is the resolution on test machine as far as I can tell) Fixed vs. auto hidden task bar might have an additional influence. Now what make it more random is the detail I skipped in my simplified explanation. The code to set the desired detail area hight works as follows: by default the details area (a StyledText) has no explicit hight hint. If the expected size (lines * line height) is larger than the available space below the dialog it set the preferred size to 75% of the available space BUT if the available space is less than the minimum of 100px nothing is set and the size results from the whole StyledText content. So for the test case the following situation arise. The first dialog as a very short test. The available space below the dialog is enough and the StyledText get a very small height hint. This hight is smaller than the minimum of 100px and the details area rendered with those 100px. For the larger text: if the space is not enough no size hint will be set, the details area grows very large and the test succeeds. If lot of space space is available the size hint is set to 75% of this space and the resulting dialog is larger than the first dialog. Test succeeds. But in the rare case that the available space is larger than the minimum of 100px but 75% of this available space is less than 100px the height is set to those 75% and the dialog will be rendered with the same minimum size as the first dialog and the test fails.
Impressive analysis, Paul. Kudos!
Gerrit change https://git.eclipse.org/r/156441 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=74be49027d01cf85d332e469933ee03012f258b5
