JDK-8121981 : [Mac,Glass] Process does not finish closing main window
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-11-27
  • Updated: 2015-06-17
  • Resolved: 2013-12-02
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
8Fixed
Related Reports
Relates :  
JDK-8087942 - Mac: Window memory leak if default close handling is used for dealing with OS close request.
Relates :  
JDK-8116226 - Mac: applications frequently hang after closing them
Description
Steps:

1. Run any JavaFX app on Mac [10.8 or 10.9, it doesn't matter].
2. Give the focus to another application.
3. Click on the red close button in the javaFX window decoration [do not give focus to javafx window].
4. The window closes but the process doesn't.

If the javafx window has the focus when you click on the red button then the process terminates correctly.
Comments
Testing: Use any FX app (e.g. HelloRectangle) and follow the instructions from the Description of the issue.
02-12-2013
The fix looks good to me
29-11-2013
+1 Rewease Wrodger!!
29-11-2013
1. You're right, the hide: call was added for exactly this reason, but currently it looks redundant I think we can remove it from FX 9 and see if anyone notices. 2. We don't use terminate: intentionally. a) this allows us to restart the run-loop should an app want to reinitialize FX (not sure if it's possible currently with FX as a whole, but in theory it should be); b) the spec for terminate: is unclear, but it sounds like it's more like exit() rather than just indicating that we don't want to use the GUI anymore. We shouldn't exit() from FX because the rest of the Java app may not be ready for exiting yet. So we only call stop: to park the main thread. 3. Correct. I have to make sure the event gets processed after the stop: call, hence I need to avoid using the performSelector call.
29-11-2013
Thoughts: I'm betting that the hide: was the code that attempted to fix the problem in 2.2, however there is no way to confirm this because the change set was not linked with the fix and there was no discussion or code review visible from the JIRA. We should not remove this hide: now although I am wondering why it is needed. Further, could we call terminate:? Again, we should not do this now. Personally, I would only make the most minimum change necessary to fix the problem (ie. post the event) at this point but I am betting if you left the performSelectorOnMainThread:, you might get into timing issues. You want to post your wake up event last. I am surprise that this is the first time that we needed to wake up the event loop like this in FX.
29-11-2013
Webrev: http://cr.openjdk.java.net/~anthony/g-18-macNoExit-RT-34554.0/ Reviewers:Steve, Petr
29-11-2013
The crux of the problem is that the Application.finishTerminating() implementation on Mac dispatches calls to [NSApp stop:/hide:] via performSelector:waitUntilDone:NO. According to its specification, the stop: method only sets a flag indicating that the run loop should terminate. The actual termination of the run loop occurs when processing an event. Selectors dispatched to the main thread are not real events. Also, an inactive app won't process any events. Thus, until we activate the app manually, the app is stuck in the [NSApp run] call and won't exit. I've verified that the finishTerminating() method can only be invoked on the event thread (the Application.terminate() performs a thread check). So we can call the stop:/hide: selectors directly. What's more, we can send a dummy event after the calls, so that the run loop can detect that we request it to terminate. I'm testing a fix and will send it for review later.
29-11-2013
Yeah. This is pretty embarrassing. I wonder how we missed it for so long. Since it isn't a regression, I think we can probably defer it.
27-11-2013
��� wow.
27-11-2013
We saw this in FX 2.x (see RT-19030) but at one time it was fixed.
27-11-2013
No, this is not a regression. I just checked and the latest 2.x release (2.2.45) has this same issue.
27-11-2013
I can confirm this on my system. I think this is a regression.
27-11-2013