JDK-8176359 : Frame#setMaximizedbounds not working properly in multi screen environments
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8,9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-03-08
  • Updated: 2021-05-01
  • Resolved: 2021-05-01
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 11 JDK 13 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 15 b10Fixed
Related Reports
Relates :  
Relates :  
Description
The issue has already been reported as bug 7010721 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7010721) and is marked as fixed. However it's still there with a different behavior. The maximized bounds of the first (default) screen will be used for the secondary screen if the screen resolution of the default screen is less than the screen resolution of the secondary screen. See also related issue http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6829250. Another related issue is https://bugs.openjdk.java.net/browse/JDK-6699851, which seems to have some root cause analysis on the behavior of maximized windows on multi screen monitors.
Comments
Please do not reopen the bugs which were closed by the pushed change. The test case you provided sets the x/y of the max bounds to zero which is the top left corner of the main screen.
01-05-2021

Please check with the provided test - the frame for the secondary screen always appears on the primary screen. Since V15 - tested on Windows 7 and Windows 10.
30-04-2021

Fix request (13u) Requesting backport to 13u for parity with 11u. Applies cleanly except the year in the copyright header of ProblemList.txt (already updated by JDK-8237869).
09-06-2020

Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.8-oracle. I had to resolve problemlist and copyrights: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/003034.html
20-04-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/2777408b8281 User: psadhukhan Date: 2020-02-11 08:55:22 +0000
11-02-2020

URL: https://hg.openjdk.java.net/jdk/client/rev/2777408b8281 User: serb Date: 2020-01-30 06:47:13 +0000
30-01-2020

there is a potential possibility of a regression -- too later for JDK 10 stabilization phase
28-11-2017

The issue is because of the following function in WFramePeer.java, which kicks in the exact same scenario: private void adjustMaximizedBounds(Rectangle b) { GraphicsConfiguration currentDevGC = getGraphicsConfiguration(); GraphicsDevice primaryDev = GraphicsEnvironment .getLocalGraphicsEnvironment().getDefaultScreenDevice(); GraphicsConfiguration primaryDevGC = primaryDev.getDefaultConfiguration(); if (currentDevGC != null && currentDevGC != primaryDevGC) { Rectangle currentDevBounds = currentDevGC.getBounds(); Rectangle primaryDevBounds = primaryDevGC.getBounds(); boolean isCurrentDevLarger = ((currentDevBounds.width - primaryDevBounds.width > 0) || (currentDevBounds.height - primaryDevBounds.height > 0)); // the window manager doesn't seem to compensate for differences when // the primary monitor is larger than the monitor that display the window if (isCurrentDevLarger) { b.width -= (currentDevBounds.width - primaryDevBounds.width); b.height -= (currentDevBounds.height - primaryDevBounds.height); } } } This fix seems to assume that the window manager doesn't correct the window size for secondary screen (that is smaller than the primary). Need to dig deeper into the fix and the related bug: https://bugs.openjdk.java.net/browse/JDK-6699851
25-11-2017

I think the reason for y coming out -34 / -27 (in my case) is because of the way the screens are aligned. In my case, screen 1 is 1920x1080 and screen 2 is 1680x1050 and the default alignment is that screen2 is about 30 pixels lower to that of screen1, so that the bottom most y is aligned. I have tried to align with top most but couldnt succeed. Although, I tried to align with arbitrarily high y value difference, and that is affecting where the window on the secondary screen (1920x1080) is getting shown.
24-11-2017

Able to reproduce the issue now. When the maxHeight -= 40 is commented out, the issue is not reproducible, but when the line is uncommented, the issue is reproducible.
24-11-2017

Please respect that the issue occurs only if the vertical size is decreased - from the posted values it looks like you haven't done this. So simply subtract e.g. 40px from the max height like I did - please take a close look at my posted values. I've also noticed that the screen insets vary when the monitors are connected in a different order.
24-11-2017

Thanks for confirming the behavior for Win7, could you also try with Win10. I have tried with Java 8, but was unable to reproduce it. Regarding the inset, I think in Win10, it allows the application to occupy the entire screen, which is why I'm seeing full size. Windows Configuration: Windows Screen 1 - 1920x1080 Windows Screen 2(primary) - 1680x1050 Current Result: Swing Screen 0 - 1920x1080 Swing Screen 1(primary) - 1650x1050
24-11-2017

The negative values are not an issue - this can be managed by setting x and y to 0 for the max bounds. With insets I've meant the screen insets returned by Toolkit.getDefaultToolkit().getScreenInsets(gc). Below you'll find the modifed test public class MultiScreen6699851Test extends JFrame { public static void main(String[] args) throws Exception { EventQueue.invokeLater(new Runnable(){ public void run() { try { JFrame.setDefaultLookAndFeelDecorated(true); new MultiScreen6699851Test(); } catch(Exception e) { e.printStackTrace(); } } }); } public MultiScreen6699851Test() throws Exception { JPanel panel = new JPanel(); BoxLayout layout = new BoxLayout(panel, BoxLayout.PAGE_AXIS); panel.setLayout(layout); panel.setBorder(new EmptyBorder(10,10,10,10)); GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsConfiguration dgc = ge.getDefaultScreenDevice().getDefaultConfiguration(); System.err.println("Main-Screen bounds: " + dgc.getBounds()); final GraphicsDevice[] gs = ge.getScreenDevices(); for (int i = 0; i < gs.length; i++) { final int screen = i; boolean primary = ge.getDefaultScreenDevice() == gs[i]; JButton button = new JButton(new AbstractAction("Create window for screen " + i + (primary ? " (Primary)" : "")){ public void actionPerformed(ActionEvent evt) { createFrame4Screen(gs, screen); } }); panel.add(button); panel.add(Box.createVerticalStrut(10)); } add(panel); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setTitle(this.getClass().getSimpleName()); pack(); setLocationRelativeTo(null); setVisible(true); } private void createFrame4Screen(GraphicsDevice[] gs, int i) { JFrame f = new JFrame(gs[i].getDefaultConfiguration()); GraphicsConfiguration gc = f.getGraphicsConfiguration(); Rectangle maxBounds = gc.getBounds(); Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc); //weird - decreasing height affects frame size maxBounds.height -= 40; maxBounds.x=0; maxBounds.y=0; f.setMaximizedBounds(maxBounds); f.setTitle("Screen " + i + " " + maxBounds); f.setExtendedState(JFrame.MAXIMIZED_BOTH); f.setVisible(true); f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); JTextPane textPane= new JTextPane(); textPane.setText("Frame bounds: " + f.getSize() + "\n" + "Screen insets: " + screenInsets); JScrollPane scroller = new JScrollPane(textPane); f.getContentPane().add(scroller); } }
24-11-2017

Just tested on Windows 7 with Java 8/9/10 - the issue still occurs. I've also noticed that the screen insets are not correct. The issue occurs only if Windows screen 2 is primary. Windows configuration: Windows Screen 1 - 2560x1440 Windows Screen 2 - 1920x1200 (primary screen with taskbar at the bottom, 82px) Expected Result (including -40px height setting): Swing Screen 0 - 2560x1400, screen insets 0,0,0,0 Swing Screen 1 (primary) - 1920x1160, screen insets 0,0,82,0 Current Result: Swing Screen 0 - 1920x1160, screen insets 0,0,82,0 Swing Screen 1 (primary) - 1920x1160, screen insets 0,0,82,0
22-11-2017

On Windows 7 VM, with JDK 9 GA, this bug is not reproducible. The primary screen size is 1680x945 and the secondary screen size is 1920x975. When I ran the test, it correctly created the windows on both screens.
21-11-2017

On Windows 10, with latest JDK-10 and JDK 9 GA, this bug is not reproducible.
27-10-2017

Tried with test provided with 7010721 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7010721) on Windows 7 with dual monitor setup. Primary screen : 1600 x 900 Secondary screen : 1920 x 1080 If program is run on primary screen, it provides two buttons to create a window on each screen. 1) On screen 0, it creates a window of size 1600 x 860 -- this behavior is correct 2) On screen 1, it creates a window of size 1600 x 860 -- this behavior is incorrect ---- this is the bug. If we swap the screens like - Primary screen : 1920 x 1080 Secondary screen : 1600 x 900 In this case, the windows are created with correct size and this bug is not observed. Same behavior is observed on 7u131, 8GA and 9b160.
14-03-2017

Ajit, please help Sergey to evaluate this issue, is it a blocker issue for 9 (I believe - No)
13-03-2017

Wolfgang, we are almost on RDP2 [1] now, in particular the last pre-integration testing build is already created for RDP2. It means only critcal stoppers are applicable to obtain approval, given this P3 is not a stopper, this is targeted to 10 now. [1] http://openjdk.java.net/projects/jdk9/
08-03-2017

The original issue is pretty old and still not completely fixed - any chance to get this fixed in Java 9?
08-03-2017