wbond on The State of Client side JavaScript Error Reporting

Comment on The State of Client side JavaScript Error Reporting

I was hoping for some info about handling the glut of false positives in Chrome when monitoring a site for JS errors using onerror. From what I can tell, they are caused by the fact that Chrome extensions run inline on pages.

It seems to me Airbrake is just requiring that you wrap all of your JS in calls to Airbrake.try(). Wouldn't this end up littering your whole app with Airbrake calls in every event handler?

oelmekki 12y

To avoid that, I check origin script url, as all my scripts are within the "/assets" path :

    window.onerror = function( error, url, lineno ){
      if ( url && url.match( //https?:\/\/.*?assets/ ) ){
        # error management
      }
    }

This ensure only relevant errors are included, discarding errors from extensions, trackers, gmaps, etc.

Of course if you inline js for performance on production code, that's a problem.

EDIT : an other important thing to avoid flooding is to handle amount of error. Javascript errors rarely come alone. An error within an event callback may be triggered several times before user surrenders. And let not even start with error within setInterval. To avoid this, I usually use a `error_got` counter and simply silence error reporting for the current page / context when I've got more than 5 errors.

And about user surrendering. Reporting errors is nice. Preventing user to get stuck is better. I always automatically disable all callbacks in onerror and let default html actions on links and form being process. This ensure user intent will be fulfilled and page context will be reloaded as a bonus. I've written more extensively on this here : https://gist.github.com/oelmekki/6420982

wbond 12y

I am filtering so only errors coming from my JS files get captured, but something in Chrome is still saying errors from other scripts are coming from mine. I know because the errors reference variables and functions that do not exist in my codebase.

I'm using this on a site with 1.5M pageviews a month, so even a very small number of errors results in quite a number of items in Rollbar. It is also effectively impossible to reproduce the issues since they are client-specific.

My current solution is to work on expanding my list of "invalid" errors that should be ignored. Based on sandstrom's comment, I'm also going to look at the Content Security Policy functionality.

jcampbell1 12y

The advantage to the try() method is you get stack traces for browsers other than Chrome. With Chrome you can get the stack trace easily. just do:

    window.onerror = function(msg,url,line,col,err) { 
      console.log(err.stack) 
    }

If that doesn't work for you, you can get it like:

    window.onerror = function() {
      console.log(window.event.error.stack)
    }

I wouldn't want litter my code with Airbrake.try(); onerror is good enough since you get stack traces from Chrome. When there is a pesky error, I tend to do something like:

    throw JSON.stringify(some_var_to_watch);

sandstrom 12y

I think errorception filters out most exception errors automatically [I'm not affiliated with them in any way, not even a customer].

Another option could be to disable all inline scripts via CSP, which will hit the older generation of Chrome extensions (and I think the newer ones doesn't trigger onerror).

lucaspiller 12y

Yeah we get tonnes of them, probably 90% of the Javascript errors we get are false positives (n.b. we aren't using the Airbrake service, just their gem with Errbit).

Here is a sample of a few we regularly get:

* Out of stack space

* TypeError: Unable to delete property.

* [object Event]

* Error loading script

* Syntax error

Comments