Mac TurboVNC Viewer: Full-screen multi-screen spanning is unreliable under Java 11

[dcommander]

I first observed this issue with OpenJDK 11.0.2, with which I couldn't make the TurboVNC Viewer span multiple screens in full-screen mode at all. After upgrading to OpenJDK 11.0.4, full-screen multi-screen spanning seems to always work when I run the viewer from my build directory using the bin/vncviewer script, but oddly, it seems to never work when I run the viewer from the Mac app bundle. In all cases, when full-screen multi-screen spanning doesn't work, the geometry is being set correctly in Viewport.setGeometry(), but (for reasons unexplained) the window is constrained to one screen or the other. I spent about 10 hours trying to debug this without success. I looked at whether the difference in behavior in the app bundle vs. the raw TurboVNC Viewer might be due to a particular key in the app bundle's Info.plist file, but I couldn't find one that had any effect on the problem. I tried offsetting the full-screen window within the multi-screen space, but the O/S refused to do that. It's as if it's clamping the window to one screen, despite the fact that "Displays have separate spaces" is turned off.

Needless to say, everything works fine with Java 8.

[dcommander]

Further info: The new issue (whereby full-screen multi-screen spanning doesn't work if the TurboVNC Viewer is launched from an app bundle) is not specific to Java 11. This gist demonstrates how to reproduce it with Java 8 as well:
https://gist.github.com/dcommander/6cd87e4f2980b741b506c9f5e7c9f29c

Make sure the appropriate version of java and javac are in the PATH, then run make to build the JAR and app. Running ./macfs will launch the app using a script, which works properly (both screens are red.) Running MacFullScreenTest.app/Contents/MacOS/MacFullScreenTest will launch the app using JavaAppLauncher in the app bundle, which does not work properly (only the left screen is red.)

I verified that:

• The same issue exists if I use the next-gen jpackage program, which will be provided with OpenJDK 14. That suggests strongly that the issue is not with JavaAppLauncher.
• The issue does not exist if I create an app bundle in which the main executable is a script similar to https://github.com/TurboVNC/turbovnc/blob/master/unix/vncviewer/vncviewer-mac.in (but using a script within an app bundle is not a particularly clean solution.)
• Various values of LSUIPresentationMode in Info.plist had no effect on the issue.

[dcommander]

TurboVNC 2.1.2 doesn't exhibit the problem, so it may be a by-product of the Xinerama feature. Investigating ...

[dcommander]

It does in fact appear to be due to JavaAppLauncher, but it's due to how that application was built, not due to the code itself. JavaAppLauncher in TurboVNC 2.1.x was built with Xcode 4.5.x, whereas JavaAppLauncher in TurboVNC 2.2.x is built with Xcode 7.x or 8.x. I'm not sure why that matters, because -macox-min-version=10.7 is passed to the compiler regardless, but perhaps the application needs to be built against the literal OS X 10.7 SDK in order to work properly in an app bundle that specifies support for 10.7 or later. Still investigating.

[dcommander]

Removing LSMinimumSystemVersion from Info.plist didn't do anything, but building JavaAppLauncher with Xcode 4.6.3 (which has the actual 10.7 SDK) fixes the problem. I wish I could explain why. I can also confirm that the problem exists with Xcode 7.2/10.11 SDK but not with Xcode 5.1.1/10.8 SDK or Xcode 6.4/10.10 SDK, so I guess the 10.11 SDK introduced it. It's certainly possible to build our official binaries with an older Xcode release, but unfortunately that isn't possible with the CI/pre-release binaries. I'm going to have to go back to including a binary of JavaAppLauncher in the source tree.