JDK-8027628 : JWindow jumps to (0, 0) after mouse clicked
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2013-10-31
  • Updated: 2013-12-05
  • Resolved: 2013-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b119Fixed
Related Reports
Duplicate :  
Relates :  
Description
JWindow jumps to (0, 0) after mouse clicked

JDK/JRE tested: 1.8.0_b112 (32/64 bits)
OS/architecture: Ubuntu 12.04
Reproducible: Always.
Is it a Regression: No
Is it a platform specific issue: Yes

To reproduce use attached file.
Steps to reproduce:
1) Resize window by mouse by 2-3 pixels
2) Release mouse button
3) Resize window by mouse by 2-3 pixels
Comments
Release team: Approved for fixing
25-11-2013

This is 8-critical-request after revisited triage, the problem is more serious than triaged before and affecting developers on Ubuntu. So the team decided to resubmit this issue as critical. Fix approved by SQE Affects real applications: The application's JWindow jumps to (0, 0) after mouse clicked, affecting Java 8 on Ubuntu 12.04. Webrev: http://cr.openjdk.java.net/~bagiras/8027628.2/ Review: http://mail.openjdk.java.net/pipermail/awt-dev/2013-November/006288.html Rationale: the fix keeps coordinates in component and its peer synchronized and as a result increases the number of tests passed. Regression test added.
20-11-2013

Yuri Nesterenko added a comment - 2013-11-19 23:20 As a response to the critical request: SQE OK to push in jdk8.
20-11-2013

HG Updates added a comment - 2013-11-18 11:27 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3ee121726c17 User: bagiras Date: 2013-11-18 19:25:41 +0000
20-11-2013

Webrev: http://cr.openjdk.java.net/~bagiras/8027628.2/ Review: http://mail.openjdk.java.net/pipermail/awt-dev/2013-November/006288.html Rational: the fix keeps coordinates in component and its peer synchronized and as a result increases the number of tests passed. Risk level: Medium. Affected component: java.awt.Window. Regression test added.
19-11-2013

The fix has been pushed to JDK 8 under JDK-8028542.
18-11-2013

Release team: Approved for deferral to 9.
07-11-2013

jdk8: SQE ok to defer!
07-11-2013

I reproduced the issue on a real machine with Ubuntu 12.04 LTS.
06-11-2013

Still cannot reproduce on VirtualBox. Will try on a real machine.
06-11-2013

I added robot to test.
06-11-2013

This is the common problem with JDK-8024631 and JDK-8014212 which were both deferred. RobotPeer.getRGBPixelsImpl() method works wrong on Linux in some cases.
06-11-2013

I couldn't reproduce "jumping" with the test attached. Tested on Ubuntu 12.04.2 LTS under VirtualBox. Andrei, could you please automize dragging somehow? I also ran mentioned tests against 3 builds (jdk8b103, jdk7u45, jdk7b147). For all of them results were as follows: TEST 1/11 1/11 AWT_ShapedAndTranslucentWindows/Automated/DNR24ShapedTest FAIL TEST 2/11 2/11 AWT_ShapedAndTranslucentWindows/Automated/DNR26ShapedByAPITest FAIL TEST 3/11 3/11 AWT_ShapedAndTranslucentWindows/Automated/DNR27StaticallyShapedTest FAIL TEST 4/11 4/11 AWT_ShapedAndTranslucentWindows/Automated/DNR28TranslucentTest PASS TEST 5/11 5/11 AWT_ShapedAndTranslucentWindows/Automated/DNR29ShapedTranslucentTest PASS TEST 6/11 6/11 AWT_ShapedAndTranslucentWindows/Automated/DNR30PerPixelTranslucentTest FAIL TEST 7/11 7/11 AWT_ShapedAndTranslucentWindows/Automated/DNR31PerPixelTranslucentGradientTest FAIL TEST 8/11 8/11 AWT_ShapedAndTranslucentWindows/Automated/DNR34PerPixelTranslucentStaticGradientTest FAIL TEST 9/11 9/11 AWT_ShapedAndTranslucentWindows/Automated/DNR35TranslucentPerPixelTranslucentGradientTest PASS TEST 10/11 10/11 AWT_ShapedAndTranslucentWindows/Automated/DNR36ShapedPerPixelTranslucentGradientTest FAIL TEST 11/11 11/11 AWT_ShapedAndTranslucentWindows/Automated/DNR37ShapedTranslucentPerPixelTranslucentGradientTest PASS For failed tests the common error was (with a similar stack trace): java.lang.RuntimeException: State 'Checking for transparency failed on point: 135, 138, color = java.awt.Color[r=97,g=173,b=225], color must be equal to background color java.awt.Color[r=0,g=0,b=0]' has not been reached in 5000 milliseconds at Waiter.ensureValue(Waiter.java:134) at DragAndResizeBaseTest.checkPixels(DragAndResizeBaseTest.java:587) at DragAndResizeBaseTest.checkShape(DragAndResizeBaseTest.java:474) at DragAndResizeBaseTest$ShapeChecker.check(DragAndResizeBaseTest.java:1272) at DragAndResizeBaseTest$Checker.check(DragAndResizeBaseTest.java:1246) at DragAndResizeBaseTest.repositionAndResizeByAPI(DragAndResizeBaseTest.java:397) at DNR26ShapedByAPITest.doTest(DNR26ShapedByAPITest.java:59) at DragAndResizeBaseTest.iterateWindows(DragAndResizeBaseTest.java:674) at DragAndResizeBaseTest.main(DragAndResizeBaseTest.java:980) at DNR26ShapedByAPITest.main(DNR26ShapedByAPITest.java:68) I double: it's NOT a regression. Seems like something is wrong with color picking.
05-11-2013

Sergey, please evaluate it, did you reproduced it?
01-11-2013