Enabling cross-origin resource sharing (CORS) can eliminate this issue, exposing JS errors to your application and allowing the errors to be captured by the New Relic Browser agent.
There are many online resources that provide information on CORS enabling and settings. This MDN article has a detailed description of CORS, with a section on configuring response headers, and another on CORS settings attributes. The Enable CORS website has information how to enable CORS for various platforms.
New Relic is not responsible for the accuracy of third-party websites.
This document is intended only as a general introduction to using CORS. Due to possible security concerns, New Relic recommends research before implementing any changes that impact the security of your application or resources. The optimal CORS implementation will depend on the systems you are using and your security considerations.
Here are general instructions on how to implement CORS:
Setting a domain, or multiple domains, will give those specific domains access to error trace details and other available resources. This MDN article may contain useful information on configuring response headers, such as adding multiple domains or using a wildcard in lieu of a domain.
<script src="EXTERNAL_LOCATION/script.js" crossorigin> </script>
This MDN article may contain useful information on CORS settings attributes.
The most common cause of this problem is the same-origin policy. This is a security policy that prevents one web resource from accessing data from another resource unless they both have the same origin. In this context, origin is the combination of the URI scheme, the hostname, and the port number. This policy prevents malicious code from gaining access to other web resources.
This is an important policy for internet security, but it can make it more difficult for web resources to work together. Specifically: if you have JS scripts hosted on CDNs or other external locations, New Relic isn't able to see the errors originating in those scripts.