1 | | With the introduction of OS X El Capitan and the //[https://developer.apple.com/library/prerelease/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_11.html#//apple_ref/doc/uid/TP40016227-DontLinkElementID_17 System Integrity Protection]// security feature, WebKit nightlies no longer work. They still launch, but the latest WebKit frameworks included inside are ignored and the system version of WebKit is used. This is because our use of `DYLD_FRAMEWORK_PATH` is ignored when launching the system Safari (specifically the `SafariForWebKitDevelopment` binary in the Safari app bundle). We are preparing a fix for this in a Safari update, but until then you can apply the following workaround. |
| 1 | //'''Note:''' You only need to apply this workaround if you are running OS X El Capitan 10.11.4 — OS X El Capitan 10.11.2 and 10.11.3 work as expected. OS X El Capitan 10.11 and 10.11.1 required a different workaround that was included in the OS X El Capitan 10.11.2 software update — see the wiki history for this page for the older workaround if you need it.// |
| 2 | |
| 3 | With the introduction of OS X El Capitan and the //[https://developer.apple.com/library/prerelease/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_11.html#//apple_ref/doc/uid/TP40016227-DontLinkElementID_17 System Integrity Protection]// security feature, WebKit nightlies and the `run-safari` WebKit command no longer works. They still launch, but the latest WebKit frameworks are ignored and the system version of WebKit is used. This is because our use of `DYLD_FRAMEWORK_PATH` is ignored when launching the system Safari (specifically the `SafariForWebKitDevelopment` binary in the Safari app bundle). If you update your Mac from a previous version of El Capitan to 10.11.4, the `SafariForWebKitDevelopment` binary gets flagged as "restricted", preventing the WebKit nightly from loading its bundled WebKit frameworks. We are exploring a fix for this in a software update, but until then you can apply the following workaround. |
13 | | 7. Type: `mkdir -p "Library/Application Support/Apple/Safari"` |
14 | | 8. Then type: `cp "Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment" "Library/Application Support/Apple/Safari/SafariForWebKitDevelopment"` |
15 | | 9. Finally type: `ln -sf "/Library/Application Support/Apple/Safari/SafariForWebKitDevelopment" "Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment"` |
16 | | * //'''Note:''' The first path of the `ln` command has a slash in front of Library and the second path does not have a slash in front of Applications, that is correct. The symbolic links needs to point to the boot location, not the booted recovery partition location in /Volumes.// |
17 | | 10. Now you can select //Restart// from the menu. |
| 15 | 7. Type: `chflags norestricted Library/Application\ Support/Apple/Safari/SafariForWebKitDevelopment` |
| 16 | 8. Now you can select //Restart// from the menu. |
19 | | A new issue was introduced with OS X El Capitan version 10.11.4. If you upgrade a Mac from a previous version of El Capitan to 10.11.4, the SafariForWebKitDevelopment binary gets flagged as "restricted", preventing the WebKit nightly from loading its bundled WebKit frameworks. |
20 | | |
21 | | To resolve this: |
22 | | |
23 | | === Steps === |
24 | | 1. Repeat steps 1-6 above to get to the appropriate volume while booted into your system recovery partition. |
25 | | 2. Type: `chflags norestricted Library/Application\ Support/Apple/Safari/SafariForWebKitDevelopment` |
26 | | 3. Now you can select //Restart// from the menu. |
27 | | |
28 | | The WebKit nightlies should work as expected after you restart. This workaround will persist and not interfere with future software updates, so there is no need to revert it later. However, you will need to reapply this workaround after updating to 10.11.1. |
| 18 | The WebKit nightlies should work as expected after you restart. This workaround will persist and not interfere with future software updates, so there is no need to revert it later. However, you might need to reapply this workaround after updating to a future 10.11.5. |