This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE Dev (Build 090921) Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b16 System: Linux version 2.6.24-24-generic running on i386; UTF-8; cs_CZ (nb) Userdir: /home/david/.netbeans/dev I have tried to run commit validation on nbbuild project from within the IDE. I will attach the screenshot demonstrating the problem. According to Marian Petras the problem is in the fact that the module tries to display too long message on one line. If you do this on GTK LAF (which is defualt on JDK6/Gnome) you will get the wrong display as demonstrated by the screen shot.
Created attachment 88106 [details] Wrong repaint problem of the JUnit results window
The JUnit module completely relays on the org.netbeans.modules.gsf.testrunner.api to render the result tree and its cells. The gsf.testrunner.api does it via functionality of the org.openide.awt . And, in result, we see a call stack like this: "AWT-EventQueue-1" org.openide.awt.HtmlRendererImpl.getTreeCellRendererComponent(HtmlRendererImpl.java:147) org.openide.explorer.view.NodeRenderer.getTreeCellRendererComponent(NodeRenderer.java:134) org.netbeans.modules.gsf.testrunner.api.ResultTreeView$DelegatingTreeCellRenderer.getTreeCellRendererComponent(ResultTreeView.java:106) javax.swing.plaf.basic.BasicTreeUI$NodeDimensionsHandler.getNodeDimensions(BasicTreeUI.java:2717) javax.swing.tree.AbstractLayoutCache.getNodeDimensions(AbstractLayoutCache.java:475) ... javax.swing.plaf.basic.BasicTreeUI.updateCachedPreferredSize(BasicTreeUI.java:1825) javax.swing.plaf.basic.BasicTreeUI.getPreferredSize(BasicTreeUI.java:1926) javax.swing.plaf.basic.BasicTreeUI.getPreferredSize(BasicTreeUI.java:1914) javax.swing.JComponent.getPreferredSize(JComponent.java:1632) javax.swing.ScrollPaneLayout.layoutContainer(ScrollPaneLayout.java:769) org.openide.explorer.view.TreeView$ExplorerScrollPaneLayout.layoutContainer(TreeView.java:1708) ... java.awt.Container.validate(Container.java:1480) org.netbeans.core.windows.view.ui.DesktopImpl$LayeredLayout.layoutContainer(DesktopImpl.java:466) ... javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:670) ... java.awt.EventDispatchThread.run(EventDispatchThread.java:122) Seems this issue is valid on GTK LAF only. (Note, the stack trace above is obtained on a Windows PC!) Learning of code and documentation of the classes from the org.openide.awt package give me an idea that their implementation might be a source of this issue, because the implementation contains many of branches executed when HtmlLabelUI.isGTK() is true. A moment that need to additionally be tested is how this issue depends on a value of the Boolean system property "nb.useSwingHtmlRendering" The HtmlRendererImpl class uses it to change own behavior . We need try to run the NetBeans with options "-J-Dnb.useSwingHtmlRendering=true" in a GTK environment and get additional info about this issue. Unfortunately, at this moment only a Windows platform is accessible to me, and I can't test it. Another moment that need to be investigated is an incorrect layout of components inside the org.netbeans.modules.gsf.testrunner.api.ResultPanelTree extending JPanel. It is container for the broken ResultTreeView. I've noticed that the org.netbeans.modules.gsf.testrunner.ResultBar (it is green/red bar 92.4% in the picture) has wrong layout, because a BorderLayout is associated with the containing JPanel (i.e. ResultPanelTree), and it is constructed in the following manner: super(new BorderLayout()); JToolBar toolBar = new JToolBar(); toolBar.setFloatable(false); toolBar.addSeparator(new Dimension(1, 0)); toolBar.add(new ResultBar()); add(toolBar, BorderLayout.NORTH); add(new ResultTreeView(), BorderLayout.CENTER); Therefore, the right border of the ResultBar must be near to the right border of the toolBar (i.e. NORTH element), and the last one must be near to the right border of the containing JPanel (ResultPanelTree), i.e. we must see the right border of the ResultBar not far from the vertical splitter. But, it is not so. The ResultBar has got a smaller width, but not expected width. If a too long string of the message is an actual cause of this issue it might be fixed in the JUnit module by adding the extra line break "\n" characters into that string if it is a plane message, or the <br/> tag if it is an HTML message. Number of such line breaks depends on both the length of that string and a desired limit of the lengths of the string in the UI components, actually they are JLabel components. But, it should be considered only as a temporary fix, and later it should be fixed in the causal place.
I've tested this issue on the Fedora 11 under Sun VirtualBox Product Version: NetBeans IDE Dev (Build 200909270201) Java: 1.6.0_0; OpenJDK Client VM 14.0-b16 System: Linux version 2.6.30.5-43.fc11.i586 running on i386; UTF-8; en_US (nb) Userdir: /home/vvg/.netbeans/dev Desktop: GNOME Version: 2.26.1; Distributor: Red Hat, Inc; Build Date: 04/29/2009 The issue is 100% reproducible after completion of a JUnit test with a simplest method like this: @Test public void testMain() { StringBuilder sb = new StringBuilder(); for(int i=0; i++<500;) { sb.append("ItsTooLong"); } fail(sb.toString()); } Note, after that test all(!) tree views may have artifacts. Seems the options "-J-Dnb.useSwingHtmlRendering=true" should never be used in such environment. The option "-J-Dsun.java2d.pmoffscreen=false" doesn't help too.
Created attachment 88593 [details] Artifacts in all visible tree views. Note, shapes of the artifacts may be changed after redraw.
Created attachment 88594 [details] With the options "-J-Dnb.useSwingHtmlRendering=true"
Created attachment 88595 [details] With the option "-J-Dsun.java2d.pmoffscreen=false"
The option "-J-Dgsf.testrunner.inline_result=false" might be useful for deep investigation of this issue: - Run NB with the option; - Complete the JUnit test proposed above. Now, you can see the artifacts only when the testMain node is expanded in the Test Results, and avoid of the artifacts when it is collapsed.
See related info in the Issue 149315
Fixed in the main trunk: http://hg.netbeans.org/main/rev/7dabf3d1f526 Too long messages are cut off up to 80 character by default. Default message length can be changed via a system property, e.g. use the option "-J-Dtestrunner.max.msg.line.length=150" for the netbeans command to set the message length to 150. Unfortunately, I've spent much time, but not found a true cause of this issue that might be fixed. Hence, this fix is only provided. My proposal about adding the extra line breaks in the long messages is not valid, because the NetBeans navigator infrastructure used to render the tree views is not intended for displaying nodes containing multi-line text. I think, UI for the unit testing should be redesigned to make it more friendly and avoid known issues.
Integrated into 'main-golden', will be available in build *200910091401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/7dabf3d1f526 User: Victor G. Vasilyev <vvg@netbeans.org> Log: Issue #172772 - JUnit results window garbled on GTK LAF.
(Commenting here via #175430) It seems a bad "fix" to break JUnit on *all* the architectures just so somebody will be able to use Junit with the GTK LnF. I mean, talk about catering the common denominator... You have a perfectly fine solution that works on Windows (probably >50% of users), OSX and Linux and just because some feature breaks the component *using a specific* look and feel we have a restriction across the board ? I would expect this fix no to include a hardcoded limit for junit "max line length" but to keep the old behavior which is *unlimited* length; only for the systems where this testrunner.max.msg.line.length is defined, you use this new value. This way the people with broken LnF just edit their .conf file and get it fixed. It doesn't make sense for the *rest* of the users to have to edit the .conf just because they exceed the msg.line.length. Also, this being something system specific, maybe the installer guys should be involved too so that my "testrunner.max.msg.line.length" is properly define to Integer.MAX_VALUE or whatever in my OSX .conf file. I don't see why all OSX/Windows users will have to google for this solution and hand edit the .conf file. Programatically I can't comment much, but I know we could either check if it's a unix system, or check the name of the look and feel, or have a separate module with a specific OS dependency, etc. There were multiple solutions basically and what I didn't like about the selected one is that it totally ignored the wast majority of other systems where JUnit was perfectly fine (at least in this regard) and added a limitation for no good reason.
Integrated into 'main-golden', will be available in build *200910270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/81b30d6cc217 User: Victor G. Vasilyev <vvg@netbeans.org> Log: #172772 - Junit tree display hard to use (possibly breaks navigation too)
*** Issue 166183 has been marked as a duplicate of this issue. ***
OK. Fixed in the main trunk http://hg.netbeans.org/main/rev/d4b9a3fc296a By default, the max line length for the messages in the Test Results window will be set to 320 only for the GTK look and feel, and it won't be limited for any other cases. Nevertheless, a user can change the default setting via the system property testrunner.max.msg.line.length in any cases.