8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" #2790

azuev-java · 2021-03-02T09:15:22Z

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Reviewers

Alexey Ivanov (@aivanov-jdk - Reviewer)
Alexander Zvegintsev (@azvegint - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2790/head:pull/2790
$ git checkout pull/2790

…ith "Exception: Failed to hide opaque button" Slightly adjusted the sequence of the waiting plus set specific min/max sizes on the component and frame. That should get rid of the incomplete painting at the start. Also added the additional screen capture that should show the state of the application after initialization and the area that will be analyzed.

bridgekeeper · 2021-03-02T09:18:21Z

👋 Welcome back kizune! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-03-02T09:19:30Z

@azuev-java The following label will be automatically applied to this pull request:

swing

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

azuev-java · 2021-03-02T09:20:43Z

I finally was able to get the failure on the test system and it seems like that was a result of the incomplete drawing of the frame at the time of screenshot taking. Here's the screenshot in full resolution - note the black part at the right part of the frame.

Setting min/max size of the frame and the content pane inside it fixes the issue so after couple of hundred of the runs i see no failures. Plus in the future should failure occur we will have better information in order to analyze the failure.

mlbridge · 2021-03-02T09:23:05Z

Webrevs

azvegint · 2021-03-02T12:06:26Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

            frw = bounds.width - insets.left - insets.right;
            frh = bounds.height - insets.top - insets.bottom;

+            imageInit = robot.createScreenCapture(new Rectangle(locx, locy, frw, frh));


Looks like the result of this screen capture is unused.

Yes, accidentally copied line instead of moving it.

aivanov-jdk

Should frame be declared as volatile? It's accessed on main thread in finally block.
In addition to it, frame.getBounds() and frame.getInsets() are called on main thread instead of EDT.

aivanov-jdk · 2021-03-02T13:26:51Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

+            BufferedImage fullScreen = robot.createScreenCapture(screen);
+            Graphics g = fullScreen.getGraphics();
+            g.setColor(Color.RED);
+            g.drawRect(locx-1, locy-1, frw+1, frh+1);


Suggested change

g.drawRect(locx-1, locy-1, frw+1, frh+1);

g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);

aivanov-jdk · 2021-03-02T13:28:44Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

+                    desktop.setMinimumSize(new Dimension(300, 300));
+                    desktop.setMaximumSize(new Dimension(300, 300));

                    frame.setContentPane(desktop);
-                    frame.setSize(300, 300);
+                    frame.setMinimumSize(new Dimension(350, 350));
+                    frame.setMaximumSize(new Dimension(350, 350));
+                    frame.pack();


Wouldn't it make {{desktop}} larger than 300,300?

It will but it forces the invalidation and repainting of the content so test does not fail.

It will but it forces the invalidation and repainting of the content so test does not fail.

Got it! It's the intention to cause additional repaint.

aivanov-jdk · 2021-03-02T13:36:37Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

                ImageIO.write(imageInit, "png", new File("imageInit.png"));
                ImageIO.write(imageShow, "png", new File("imageShow.png"));
+                ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
                throw new Exception("Failed to show opaque button");


~~I suggest moving saving the images into a new method.~~

I see the set of images is different each time. Probably it makes sense to save all the images which are non-null, what do you think?

I don't think it is necessary. And since this is an existing test i'm trying not to change its overall behavior and having screenshots at other stages of the testing is not beneficial in the test debugging.

aivanov-jdk · 2021-03-02T13:45:07Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

            if (Util.compareBufferedImages(imageInit, imageShow)) {
                ImageIO.write(imageInit, "png", new File("imageInit.png"));
                ImageIO.write(imageShow, "png", new File("imageShow.png"));
+                ImageIO.write(fullScreen, "png", new File("fullScreenInit.png"));
                throw new Exception("Failed to show non-opaque button");
            }


Does it make sense to move this block above before invokeAndWait to make the sequence of actions consistent?

Well, functionally it will not make any difference, we are analyzing the screenshots and the only thing that matters is at which time screenshot was taken. The only reason we don't take all screenshots in the beginning and analyze them later is to save test run time if test runs early. At the end it is not critical anymore. And as i said this is an existing test so i'm trying not to change it unless it affects its functionality.

Yes, I agree it makes no difference. Yet when you read the test code, the pattern — show or hide the button, take screenshot, analyze it — gets broken. This place is the only exception to the pattern; here the button is shown, screenshot is taken, then the button is hidden and only after hiding the button the screenshot is analyzed, which could give the wrong impression as if the screenshot after hiding the button is being analyzed here.

Ok, i give up, you won - i'll fix it.

mrserb · 2021-03-02T18:14:12Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java


-            robot.delay(1000);
            robot.waitForIdle(1000);
+            robot.delay(1000);


I doubt that this is a test issue, 2 seconds was not enough to properly show the frame?

The problem is that i tried to reproduce this behavior locally on Ubuntu running this test (and the simplified version of it) literally millions of times. The only time it fails is when it is run on mach5 and even then it fails very rarely - once per hundreds of runs. The changes here - especially forcing the resize - seems to eliminate the problem with mach5.

Then it is a product bug, If the problem is unrelated to the performance and the root cause is in the wrong/broken final layout. Do we want to suggest the same thing if the user will get the same issue in their app?

It might be a product bug. Or it might be something specific to the machines with mach5 system. Or to some specific machine having hardware issue (i noticed that in my case all failures happened on one specific Linux test system). That's the problem. I have a simplified test case that should check for that specific problem and i'm running a dedicated Linux host in my home office with the same OS version than problematic machine that does nothing but runs this test in interactive mode for days. Today only i ran this test over 700000 times - 0 failures. If i would have a way to at least semi-reliable reproduce the problem i would create a new bug and would debug and fix it. But i don't. And the changes i made is simply a way to let this test to run even on the problematic host because the problem that happens have nothing to do with the functionality related to the test itself.

aivanov-jdk · 2021-03-02T23:21:49Z

Should frame be declared as volatile? It's accessed on main thread in finally block.
In addition to it, frame.getBounds() and frame.getInsets() are called on main thread instead of EDT.

I couldn't link this comment to the code because GitHub does not allow adding comments to unmodified lines. Do I understand correctly that you're for leaving it as is?

azuev-java · 2021-03-03T04:53:29Z

Should frame be declared as volatile? It's accessed on main thread in finally block.
In addition to it, frame.getBounds() and frame.getInsets() are called on main thread instead of EDT.

I couldn't link this comment to the code because GitHub does not allow adding comments to unmodified lines. Do I understand correctly that you're for leaving it as is?

Pretty much. Making frame volatile will not change the behavior, the assignment to it made in one place and it's on EDT inside invokeAndWait block, making it volatile will change nothing, it will be fully assigned by the time we leave EDT. And calling non-disruptive getters such getInsets or getBounds from main thread is not a problem either. By that time frame should be visible and in position - otherwise we will have much more interesting problems.

openjdk · 2021-03-03T10:11:33Z

@azuev-java This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Reviewed-by: aivanov, azvegint

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 128 new commits pushed to the master branch:

0265ab6: 8262466: linux libsaproc/DwarfParser.cpp delete DwarfParser object in early return
c15801e: 8261142: AArch64: Incorrect instruction encoding when right-shifting vectors with shift amount equals to the element width
044e2a2: 8183569: Assert the same limits are used in parse_xss and globals.hpp
5de0f4b: 8260869: Test java/foreign/TestHandshake.java fails intermittently
c9097a6: 8262893: Enable more doclint checks in javadoc build
40bdf52: 8262096: Vector API fails to work due to VectorShape initialization exception
93ffe6a: 8262892: minor typo in implSpec comment
4f4d0f5: 8261969: SNIHostName should check if the encoded hostname conform to RFC 3490
c92f3bc: 8262876: Shenandoah: Fix comments regarding VM_ShenandoahOperation inheritances
20b9ba5: 8262875: doccheck: empty paragraphs, etc in java.base module
... and 118 more: https://git.openjdk.java.net/jdk/compare/18188c2aa7d68f057d4e08d70944d5694dbe73a2...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

prsadhuk · 2021-03-04T02:56:05Z

test/jdk/javax/swing/JComponent/7154030/bug7154030.java

+            BufferedImage fullScreen = robot.createScreenCapture(screen);
+            Graphics g = fullScreen.getGraphics();
+            g.setColor(Color.RED);
+            g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);


I believe we need to call g.dispose to dispose this object which we normallydo after getGraphics() call.

It is not necessary in such a short test, JVM will exit after test ends which will clear all the resources captured by this Graphics instance.

BTW it will be closed/released only if the tests are run in the othervm mode, but jtreg tests might share the single VM for a group of tests.

azuev-java · 2021-03-05T20:59:32Z

/integrate

openjdk · 2021-03-06T09:12:11Z

@azuev-java Since your change was applied there have been 175 commits pushed to the master branch:

75a5be8: 8263054: [testbug] SharedArchiveConsistency.java reuses jsa files
2afbd5d: 8250804: Can't set the application icon image for Unity WM on Linux.
fa43f92: 8261845: File permissions of packages built by jpackage
23ee60d: 8261008: Optimize Xor
e1cad97: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java
2c0507e: 8261812: C2 compilation fails with assert(!had_error) failed: bad dominance
9755782: 8157682: @inheritdoc doesn't work with @exception
8c13d26: 8263050: move HtmlDocletWriter.verticalSeparator to IndexWriter
8d3de4b: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3
75fb7cc: 8259228: Zero: rewrite (put|get)field from if-else chains to switches
... and 165 more: https://git.openjdk.java.net/jdk/compare/18188c2aa7d68f057d4e08d70944d5694dbe73a2...master

Your commit was automatically rebased without conflicts.

Pushed as commit 5eb2091.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

openjdk bot added swing client-libs-dev@openjdk.org rfr Pull request is ready for review labels Mar 2, 2021

azvegint reviewed Mar 2, 2021

View reviewed changes

aivanov-jdk reviewed Mar 2, 2021

View reviewed changes

mrserb reviewed Mar 2, 2021

View reviewed changes

Minor fixes.

2c6594c

Moved checking block up to keep consistency of operations.

0bfe02f

aivanov-jdk approved these changes Mar 3, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 3, 2021

azvegint approved these changes Mar 3, 2021

View reviewed changes

prsadhuk reviewed Mar 4, 2021

View reviewed changes

openjdk bot closed this Mar 6, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Mar 6, 2021

mrserb mentioned this pull request Jul 17, 2021

8268284: javax/swing/JComponent/7154030/bug7154030.java fails with "Exception: Failed to hide opaque button" #4792

Closed

3 tasks

azuev-java deleted the JDK-8261689 branch August 23, 2021 19:39

	g.drawRect(locx-1, locy-1, frw+1, frh+1);
	g.drawRect(locx - 1, locy - 1, frw + 1, frh + 1);

8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" #2790

8261689: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" #2790

Uh oh!

Conversation

azuev-java commented Mar 2, 2021 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Mar 2, 2021

Uh oh!

openjdk bot commented Mar 2, 2021

Uh oh!

azuev-java commented Mar 2, 2021

Uh oh!

mlbridge bot commented Mar 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aivanov-jdk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aivanov-jdk commented Mar 2, 2021

Uh oh!

azuev-java commented Mar 3, 2021

Uh oh!

openjdk bot commented Mar 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

azuev-java commented Mar 5, 2021

Uh oh!

openjdk bot commented Mar 6, 2021

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

azuev-java commented Mar 2, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Mar 2, 2021 •

edited

Loading

openjdk bot commented Mar 3, 2021 •

edited

Loading