JDK-8183572 : WToolkit does not call displayChanged
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u111,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: other
  • CPU: x86
  • Submitted: 2017-06-30
  • Updated: 2018-05-21
  • Resolved: 2018-05-21
Related Reports
Relates :  
JDK-8162507 - Popup menu in JWS application appears on wrong screen after disconnecting and connecting screen
Description
FULL PRODUCT VERSION :
1.8.0_111

ADDITIONAL OS VERSION INFORMATION :
Windows 10 Pro Version	10.0.15063 Build 15063


A DESCRIPTION OF THE PROBLEM :
Dialogs, Menu Items and Context Menus appear on wrong screen when a JFrame is positioned on a secondary display that has been (re)connected AFTER application launch.

This ONLY happens when the application is launched using JWS.

"Manually" calling WToolkit.displayChanged() cures the problem.
This method is called by the evenLoop() when I debug the application in my IDE and connect my secondary display.

Therefor my conclusion is that this does not happen under JWS.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a simple JFrame application with a menu bar and some menu items.
One item might call the WToolkit.displayChanged().

Launch the application using JWS from web server
Physically connect a secondary display to your laptop, it should extend your desktop.
Drag the frame to the secondary display.
Click the Menu Bar.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Menu Items should appear underneath the Menu Bar
ACTUAL -
Menu Items appear on the primary display

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
GraphicsEnvironment environment = GraphicsEnvironment.getLocalGraphicsEnvironment();

if (environment instanceof DisplayChangedListener)
	EventQueue.invokeLater(((DisplayChangedListener)environment)::displayChanged);
Comments
Submitter is able to reproduce this issue. Additional note, below: ========================= My screen resolution is 1920 x 1080 on both displays, but this is probably not a factor since we have this problem on all sorts of combinations, projectors, tv:s, different laptops etc. Only common denominator is that we always run on laptops. Attached you will find an archive with an updated version of the project. Here's a recording of the case https://youtu.be/qJyuHWwMBBQ Note that the class path (shown in the main frame) ONLY consist of deploy.jar ================================== Not able to reproduce this locally with similar resolution (1920X1080) on both screens. However, as submitter demonstrate this as reproducible (link above) marked as open for further investigation.
06-07-2017
Received following update the submitter confirming that the issue still persists. =========================================================== I actually just ran it on 9 and the bug is still there as well. Also, the Update Displays did not work on 9, but I have not looked into that, all I know is that it did not work in runtime. When I ran Update Displays on version 8 it cured the problem. I've added some system info to the Main Panel as you can see in the picture. I'm using a Lenovo ThinkPad W540. In this case with 9 and with latest 8 I just hooked up wirelessly to my Bravia TV and extended my desktop to that. The problem occurs ONLY when the application is started via JNLP AND the second display is attached AFTER the application is launched. This is a major hassle to our consultants and customers since our software often is brought into demos and conferences while running and then hooked up to whatever projectors or screens that are available in the room. Here's an image of the result after I dragged the frame to the top screen (TV) and hit the button... ===================================================================== Reopening the report, while seeking additional information including actual display type and resolution.
06-07-2017
The submitter has reported that Dialogs/Menu Items or Context menus have appeared on the wrong screen when a JFrame is positioned on a secondary display when launched using JWS. Checked this for 8u112, 8u131 and 9 ea b176 and couldn't reproduce as reported (see attached image as a reference). 8u111: OK 8u131: OK 9 ea b176: OK To verify run the attached test case (subsequent comment). The test requires multi-monitor (secondary screen) set up. Writing back to the submitter requesting additional information or clarification about the result.
05-07-2017