Modifying com.apple.Safari.plist File with macOS Sierra 10.12

[sepiemoini]

All,

I am trying to modify the com.apple.Safari.plist to AllowJavaScriptFromAppleEvents -bool TRUE and have been led to believe that the command below previously worked, prior to OS X El Capitan. To achieve this manually, one would do the following:

1. Launch Safari, go Preferences>Advanced and check Show Develop menu in the menu bar.
2. From the menu bar, go to Developer and check the Allow JavaScript from Apple Events.
3. Authenticate with administrative credentials.

Since this isn't a great workflow to have users manually do this on their own, I'd like to automate this if possible. I'm not having much success with the short script below and was wondering if anyone has attempted to do this with more success running macOS Sierra 10.12 and Safari 10.

#!/bin/bash
defaults write ~/Library/Preferences/com.apple.Safari.plist AllowJavaScriptFromAppleEvents -bool TRUE
exit 0

The above command seemingly works (i.e. no errors and running a defaults read command shows that the AllowJavaScriptFromAppleEvents is set to TRUE or with a value of 1) but the Safari settings do not indicate that these were modified as they were with the manual process shown first. Keep in mind that this will largely be applied to macOS devices that are already deployed with users having already customized their own Safari settings so packaging a DMG with Composer with FEU and/or FUT enabled isn't a viable option. Thoughts?

[mm2270 · Accepted solution]

@sepiemoini The key still seems to be there for me. I just ran a quick capture in Composer by enabling that setting, and I see that key and boolean value in the com.apple.Safari.plist that Composer grabbed. However, I suspect that entry is only one piece of the puzzle. Making a change in a users Safari plist would never require entering an admin password. That indicates it's actually making some other change somewhere deeper in the OS and the key in the plist just tells Safari that the option is enabled that it can use.

Unfortunately, Composer didn't capture anything else of relevance, so wherever the setting is getting applied, it's not something very standard. Which leads me to believe it won't be possible to script this. I could be wrong, but it isn't looking too good.

[davidacland]

Someone had a similar question a few days ago about disabling caches in Safari from the develop menu.

I had a look at the time and couldn't see any related key in the safari.plist.

It is quite possible that this setting isn't stored in that plist anymore, or if it is, the key is called something else.

You could use something like Composer or FSMonitor to track what files are being edited when you enable the setting to see if it can be scripted / automated.

[sepiemoini]

@davidacland Yup, looks like Apple did away with this key in the specified Safari plist as of OS X El Capitan (or around then) so modifying this is useless.

[mm2270 · Accepted solution]

@sepiemoini The key still seems to be there for me. I just ran a quick capture in Composer by enabling that setting, and I see that key and boolean value in the com.apple.Safari.plist that Composer grabbed. However, I suspect that entry is only one piece of the puzzle. Making a change in a users Safari plist would never require entering an admin password. That indicates it's actually making some other change somewhere deeper in the OS and the key in the plist just tells Safari that the option is enabled that it can use.

Unfortunately, Composer didn't capture anything else of relevance, so wherever the setting is getting applied, it's not something very standard. Which leads me to believe it won't be possible to script this. I could be wrong, but it isn't looking too good.

[sepiemoini · Accepted solution]

As per usual, thank you for your input, @mm2270! The entry does populate for me only after I run the defaults write command but seems to be ineffective as well. I've alerted our team handling the larger project that this feature cannot be implemented as I originally speculated.

[mm2270]

This stackoverflow thread seems to confirm your findings. Others could not get it to enable with just the defaults option under 10.11 and up either. It might now be under the protection of SIP, whatever it's actually modifying.