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

sepiemoini
Contributor III
Contributor III

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. c75dcc9310d34681861d091cbab49192
  2. From the menu bar, go to Developer and check the Allow JavaScript from Apple Events. 7699f5f831fe45b1b4d3d635ef19f4a0
  3. Authenticate with administrative credentials. 185a9e57c8d1447d931de6a3237d23bb

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?

2 ACCEPTED SOLUTIONS

mm2270
Legendary Contributor III

@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.

View solution in original post

sepiemoini
Contributor III
Contributor III

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.

View solution in original post

5 REPLIES 5

davidacland
Honored Contributor II
Honored Contributor II

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
Contributor III
Contributor III

@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
Legendary Contributor III

@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
Contributor III
Contributor III

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
Legendary Contributor III

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.