Firefox 37.0.1 always just reports "Script Error", Chrome works OK

Hi,

We are attempting to get Raygun setup. Our application makes requests to our own API, as well as a remote API. The errors that come back from the remote API look like this:

Object { status: 400, message: "{
    "error": {
        "code": 400,
        "message": "Failed to parse UUID",
        "type": "invalid_request_error"
    },
    "result": "error",
    "transaction_id": "fb5261d7-97f0-49c9-abe4-e6e47cfaec61"
}" }

Our application code looks like this:

  if (response instanceof Error) {
        Raygun.send(response);
        throw response;
   }

In Chrome, this works fine and yields a fairly informative report in the Raygun app. In Firefox, we never get anything in the app other than "Script Error". We've tried whitelisting the remote API's domain, leaving us with this for our Raygun init:

require('raygun4js');
Raygun.init(process.env.RAYGUN_APIKEY, {
  debugMode: true
}).whitelistCrossOriginDomains(['api.company.com'])
  .attach();

However, still nothing. We have also tried just sending through strings and other simple data, but regardless of what we do, Firefox just ends up with "Script error". Any ideas? Thanks for your help.

Mark and Kristina

---

Hi,

For this scenario, we have a bit of documentation at https://raygun.io/docs/languages/javascript under "Errors in scripts on other domains" which you may have seen. It appeared at the time (and still seems to be the case) that FF's implementation provides minimal data as you've noticed when the third-party domain lacks the Access-Control-Allow-Origin header.

Try setting that header to include the domain where your site is loaded from. You may also need to set the crossOrigin attribute on the script tag, possibly to continue to get good traces from Chrome. As is obvious the spec around this varies wildly and the browser's implementations are prone to change beneath us, so the ideal path is to get the stack traces where you can and use those to tighten up the bugs.

Hope this helps,

Callum Gavin
Mindscape Limited

---

The response from the third party domain includes the Access-Control-Allow-Origin header:

RESPONSE:

Access-Control-Allow-Origin: http://localhost:3000
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 300
Content-Type: application/octet-stream
Date: Tue, 14 Apr 2015 17:51:47 GMT
Server: gunicorn/18.0
Strict-Transport-Security: max-age=31536000

The origin in that header matches the origin in the request from our app:

REQUEST:

Host: api.domain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Authorization: Basic LmxpOHRLTjdkbVROMEV2WHNwMmswS1Ixa2RUUWNSX04tcHRHR1plSmc5am1yT01WOU1ZaTfancystricystrfancTYtring0hiZjcyODdLU1JfRkwzTzZ0ME1zR2o1QmpSS0JYZTFDYjZ2Q29ReWllbG1tX0fg4Q1M3RkU0R3kxQVc4NVFTZWhocWlSMVNOSEpXdmVIeDE2TGlrLkNBM3FRAAaZy5VQ1RYWnIwOGN6RRRRakZKUDFfRnN5N2xsaGZ0LTA6
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:3000/referrals/d756e0e7-d621-43a9-a1e1-dac1ca01f4d6/
Origin: http://localhost:3000
Connection: keep-alive

Is there something else we should be doing? Thanks for your help,

Mark

---

Try adding "crossorigin" to your script tag so it looks like:

<script src="http://api.domain.com/foo.js" crossorigin></script>

---