Error Messages are not given to the onerror callback when script is hosted on different domain than site. The following Bug has regressed: https://bugs.webkit.org/show_bug.cgi?id=70574 Try Testcase http://trackjs.com/demo/bug.html in Safari 7.
<rdar://problem/30270046>
https://errorception.com/docs/cors
This also appears to affect window.onunhandledrejection, except that in that case, the event isn't fired at all.
https://stackoverflow.com/questions/45844565/script-error-errors-in-window-onerror-in-safari-only This bug was open in 2014. Is there any plan to fix it?
ScriptExecutionContext::dispatchErrorEvent checks for CORS. If a CachedScript is provided, it works as expected. If the error is thrown synchronously when executing a script, I think sanitization will work as expected. In the particular stackoverflow case, the exception is thrown in an event handler so we do not have any CachedScript at hand. In that case, we rely on the sourceURL which is cross-origin. One option is to continue relying on the existing mechanism and ensure we pass a CachedScript& everywhere. Another option is to try to retrieve the sanitization information directly from the Exception, like we are retrieving the sourceURL/line... from it. It seems to me the latter would scale better.
Over two years ago it was asked if this issue would be addressed, as it had been present since at least 2014. It is a continuation of a WebKit issue (70574) from 2011 which was essentially the same. Though it appears there are some suggestions as to how a patch could be designed, it looks like there is still no movement on this ticket. I unfortunately do not have the intricate knowledge of WebKit to fix this effectively. What I can do however is describe why I think this is a critical issue to be repaired by someone, hopefully someone who actually gets paid to hack WebKit. This may be a repeat of things said previously in various forums on this topic but it's likely worth repeating for clarity and to try and nudge this ticket. 1. Modern web applications are getting larger and as a result are using code-splitting to load portions of apps at a time. For most apps this is critical for performance, and you get negative repercussions from google and other search engines when your page load speeds are slow and your app doesn't meet certain core web vital benchmarks. In order to compete in the current landscape you essentially must split your code, and if you use a CDN (also a must for the same competitive reasons) your code is now loading cross origin in segments. 2. As apps get more complex they have more code and thus more places to potentially have errors. If you are deploying a complex webapp and want to support the largest possible array of devices/browsers you will inevitibly also need to install some instrumentation, specifically a browser error logger like datadog, rollbar or the like to capture device and browser specific issues. Even if you try to test multiple combinations locally the permutations of device/browser/version etc are too great to cover and capturing real errors in the wild is the only way to actually find and fix them. 3. If your users are in a Chromium/Chrome based or Gecko/Firefox based browser, the window.onerror / error event listener gets a usable error message and stacktrace to report back to your logs, so you can see what went wrong. If you want this to work cross origin you have to ensure your script tags have the correct attributes set and your server returns acceptable CORS headers, but it is possible to configure this correctly. 4. If your users are using a WebKit/Safari based browser, you are completely out of luck and only have the string 'Script Error' to inform you that an error happened with no context whatsoever. The cross origin configuration that corrects the issue on other browsers has no effect. WebKit seems to be the only outlier here, and it is specifically problematic because of the prevalence of iOS devices. It seems to me that this is a serious problem, mainly because it incentivizes developers to make poor choices for performance that negatively effect their projects and their end user experiences. If you have a lot of iOS users and want to do proper error reporting you have to abandon code splitting all together. I think it's likely that old versions will never be patched and it'll always be an issue, but a decent amount of the iOS user population does update regularly enough that it would be impactful to have this fixed in new versions of WebKit. It's less of a problem for my usecase/userbase, but obviously this also has an effect on desktop safari error reporting. Any information on workarounds or other suggestions are welcome, but I really do think the only way to solve this is to fix the underlying behavior. Thanks P.S. I did try to dig for a spec document that prescribes the CORS behavior that exists in chromium/gecko but could not find anything, though there are references in old mailing lists to discussions about it.