This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread.
When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into eventloopjam - Background information on how Mac Glass handles invokeLater runnables - Unblock invokeLater runnables when entering new loop just after exiting current one Changes: https://git.openjdk.org/jfx/pull/1449/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285893 Stats: 58 lines in 3 files changed: 58 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1449.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/jfx/pull/1449
