Changes between Version 14 and Version 15 of WebKitNightlyElCapWorkaround
- Timestamp:
- Mar 23, 2016, 8:39:25 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TabularUnified WebKitNightlyElCapWorkaround
v14 v15 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 pagefor the older workaround if you need it.//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/WebKitNightlyElCapWorkaround?version=12 wiki history of this page] for the older workaround if you need it.// 2 2 3 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.