JDK-8041734 : JFrame in full screen mode leaves empty workspace after close
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7-pool,8-pool,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2013-12-19
  • Updated: 2017-05-24
  • Resolved: 2014-09-23
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 JDK 9 Other
8u40Fixed 9 b36Fixed openjdk7uFixed
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b120)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Mac OS X 10.9

A DESCRIPTION OF THE PROBLEM :
The problem reproduces on both JDKs 1.7.0_45 and 1.8.0-ea-b120

If you have two or more JFrames in full screen mode and close one of the frames, there will be an empty grey screen and empty toolbar menu.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Open IntelliJ IDEA
2. Open two or more projects
3. Send all windows to full screen
4. Close one of the projects by Main Menu -> File -> Close project

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Empty workspace should be removed from available spaces.
ACTUAL -
Grey empty screen

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.lang.reflect.Method;

/**
 * @author Konstantin Bulenkov
 */
public class MacWorkspacesBug extends JFrame {
  public MacWorkspacesBug(String title) throws HeadlessException {
    super(title);
    setSize(500, 500);

    final JButton close = new JButton("Close");
    close.addActionListener(new ActionListener() {
      @Override
      public void actionPerformed(ActionEvent e) {
        setVisible(false);
      }
    });
    getContentPane().add(close);
  }

  public static void enableOSXFullscreen(Window window) {
    try {
      Class<?> util = Class.forName("com.apple.eawt.FullScreenUtilities");
      Method method = util.getMethod("setWindowCanFullScreen", Window.class, Boolean.TYPE);
      method.invoke(util, window, true);
    } catch (Exception ignore) {
    }
  }

  public static void main(String[] args) {
    final MacWorkspacesBug f1 = new MacWorkspacesBug("Frame 1");
    final MacWorkspacesBug f2 = new MacWorkspacesBug("Frame 2");
    enableOSXFullscreen(f1);
    enableOSXFullscreen(f2);
    f1.setVisible(true);
    f2.setVisible(true);
  }
}

---------- END SOURCE ----------
Comments
https://code.google.com/p/chromium/issues/detail?id=156101
23-09-2014

Oh, well. Nobody complained yet. Anyway, if you can improve this behavior in JDK, this is fine. In that case, I'd also ask you to file a P4 Tweak issue against Glass to implement a similar solution for JavaFX. Thanks in advance.
11-09-2014

I rechecked FX behaviour, and it works in the same way as if I call toggle before orderout. It is different from jdk 6 or native.
11-09-2014

When you call toggleFullScreen:, the operating system indeed starts an animation. If you want to wait until it completes, you can start a nested event loop after calling toggleFullScreen:, and wait until you receive a windowDidExitFullScreen: on the window delegate, after which you terminate the nested loop and continue with a call to orderOut:. We use a similar technique in Glass in JavaFX when handling the OS X 10.7 full screen, and it works fine for us.
11-09-2014

Will try two solutions: - close +setReleasedWhenClosed:NO - toggle before the orderout.
11-09-2014

> I suggest to check whether the window is in the full screen mode before hiding it, and if it is, then call toggleFullScreen: before calling orderOut:. This approach was the first one which I tried, but it does not work well, the animation effect is differ from the native application or jdk6.
11-09-2014

The difference is that orderOut: hides the window but keeps it alive, while close: also releases the window. So, orderOut: allows us to reuse the same NSWindow instance between showing/hiding a window w/o destroying the actual Cocoa window. To fix this bug, I suggest to check whether the window is in the full screen mode before hiding it, and if it is, then call toggleFullScreen: before calling orderOut:.
11-09-2014

Can be an OSX bug, if I change the nswindow.orderOut call to nswindow.close the problem goes away.
11-09-2014

The bug was reproduced with JDK 9 b09, JDK 8u5 b13, JDK 7u55.
24-04-2014