JDK-8092977 : Mac: FileChooser.show() crashes in NSSavePanel when running in sandboxed environment
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8u20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-05-23
  • Updated: 2020-01-06
  • Resolved: 2014-07-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 8
8u40Fixed
Related Reports
Duplicate :  
JDK-8095317 - Glass File Dialogs fail in sandboxed Mac App Store app
Duplicate :  
JDK-8095962 - [Mac] Sandboxed JavaFX App crashes when calling Directory and/or File Chooser
Relates :  
JDK-8234474 - [macos 10.15] Crash in file dialog in sandbox mode
Relates :  
JDK-8236685 - [macOs] Remove obsolete file dialog subclasses
Description
I wrote a sample FX app, built a Mac Bundler using latest javapackage
and sandboxed it using Apple codesign.

When my app tries to show its FileChooser, it crashes with the stack below.
FX2 FileChooser used to work in sandboxed environment : so its looks
like a FX8 regression.


May 22 15:44:23 dhcp-grenoble-10-166-105-209.fr.oracle.com
<http://dhcp-grenoble-10-166-105-209.fr.oracle.com/> SandBoxer[10716]:
An uncaught exception was raised
May 22 15:44:23 dhcp-grenoble-10-166-105-209.fr.oracle.com
<http://dhcp-grenoble-10-166-105-209.fr.oracle.com/> SandBoxer[10716]:
GlassOpenPanel is not a supported subclass for sandboxing
May 22 15:44:23 dhcp-grenoble-10-166-105-209.fr.oracle.com
<http://dhcp-grenoble-10-166-105-209.fr.oracle.com/> SandBoxer[10716]: (
0   CoreFoundation                      0x00007fff90e4325c
__exceptionPreprocess + 172
1   libobjc.A.dylib                     0x00007fff8cfd5e75
objc_exception_throw + 43
2   CoreFoundation                      0x00007fff90e4310c
+[NSException raise:format:] + 204
3   AppKit                              0x00007fff8f4562f1
+[NSSavePanel newRemotePanel] + 157
4   AppKit                              0x00007fff8f456445
+[NSSavePanel _crunchyRawUnbonedPanel] + 120
5   libglass.dylib                      0x00000001267a21cf
Java_com_sun_glass_ui_mac_MacCommonDialogs__1showFileOpenChooser + 319
6   ???                                 0x00000001095f766e 0x0 +
4452218478
)


Here is the entitlements I passed to codesign:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
</dict>
</plist>
Comments
David, Petr: thanks for the review.
01-07-2014
Changeset: dbfe7fd6bd15 Author: Anthony Petrov <anthony.petrov at oracle.com> Date: 2014-07-01 16:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dbfe7fd6bd15
01-07-2014
Oh, that's me who missed one of the checks, sorry. The new version looks good.
30-06-2014
Good catch with the missing CFRelease() call. I've updated the fix: http://cr.openjdk.java.net/~anthony/g-44-NSSavePanelSandbox-RT-37261.1/ Petr: I'm not sure what you're talking about. In GlassDialogs.m I'm using the same technique for Open, Save, and the Folder dialogs. Did I miss an isSandbox check somewhere else?
30-06-2014
Agree with David's concern about releasing the variable. Also, shouldn't we handle the savePanel similarly?
30-06-2014
Does SecRequirementRef sandboxRequirementRef need to be released? The rest looks fine.
27-06-2014
David, Petr: please see the above comments for a link to the webrev. Eric: thank you for testing the fix.
27-06-2014
I've checked Anthony's fix with my sandboxed app : I confirm it fixes the issue.
27-06-2014
I'm not set up for codesigning and sandboxing, so I've tested my developer build with a simple JavaFX application that shows a file chooser. Everything seems to work fine. I've added debugging output to the +isSandbox method and I confirm that it correctly determines that the app isn't signed, and hence it skips the main check and reports that the application is not sandboxed.
26-06-2014
The following fix should resolve the issue: http://cr.openjdk.java.net/~anthony/g-44-NSSavePanelSandbox-RT-37261.0/ I'm checking if the running application is sandboxed, and if so, I use the NSOpenPanel and NSSavePanel classes directly. If not, then I continue to use our custom descendants of those classes (GlassOpenPanel and GlassSavePanel correspondingly). Limitation of the fix: When running in a sandboxed environment, key-shortcuts for Cut/Copy/Paste operations won't work in the file dialog's file name edit box. There's no workaround for this issue.
25-06-2014
First analysis done by Anthony: >> This looks like a problem in Glass. We subclass the NSSavePanel in order to process Cmd+C, V, and X shortcuts (copy, paste, cut >> operations) in the filename textfield. And it looks like OS X doesn't like subclassed file dialogs. >> >> Either, we can drop the support for Edit commands in file dialogs (but this will be a regression), or turn it off only for sandboxed apps >> somehow.
23-05-2014