Chrome extension: how to trap/handle content-script errors globally?

Question

In a Chrome extension, is there a way to globally trap/handle Javascript errors occurring in a content-script? (e.g. for submission to a Javascript error tracking service like bugsnag)

Ideally, I would setup a global window.onerror handler at the top of the content script. But it's not working properly in Chrome 40: the error is caught, but the information supplied is useless: a message of 'Script error' and no url, lineNumber, column or error object with stack.

I created a test extension to show this busted behaviour for content scripts. Details below. Interesting findings:

window.onerror works correctly in a background script, with full error information
window.onerror on the hosting webpage can also see the error thrown by an extension content script (but the error doesn't contain any useful info either)

Reproducing busted window.onerror for Chrome extension content script.

In a new folder, create manifest.json, content-script.js and background-script.js. Then load into Chrome via Window > Extensions > Load unpacked Extension.

To see the busted window.onerror info for a content-script error, reload a webpage and look at the devtools console

manifest.json

{
    "name": "Chrome extension content-script errors test",
    "manifest_version": 2,
    "version": "0.0.1",
    "background": {
      "scripts": [ "background-script.js" ]
    },
    "content_scripts": [{
        "matches": ["<all_urls>"],
        "js": ["content-script.js"]
    }]
}

content-script.js

window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {
    console.log('Caught content script error');
    console.log('errorMsg: ' + errorMsg);
    console.log('url: ' + url);
    console.log('lineNumber: ' + column);
    console.log('column: ' + column);
    console.log('errorObj follows:');
    console.log(errorObj);
    return true;
};

console.log('I am a content script, about to throw an error');
throw new Error('Is this error caught?');

background-script.js

window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {
    console.log('Caught background script error');
    console.log('errorMsg: ' + errorMsg);
    console.log('url: ' + url);
    console.log('lineNumber: ' + column);
    console.log('column: ' + column);
    console.log('errorObj follows:');
    console.log(errorObj);
    return true;
};

//To see nice window.onerror behaviour for background script..
//Uncomment 2 lines below, reload extension, and look at extension console
//console.log('I am a background script, about to throw an error');
//throw new Error('Is this error caught?');

Until that Chrome bug is fixed, here is a method to capture errors in the webpage context. You'll have to sort out if the error comes from the page or from your content script though. stackoverflow.com/a/20399910/1507998 — rsanchez
I already tried the approach described, and it's not working for me. window.onerror within the hosting webpage does indeed trap the error thrown from the extension content script. But the errorEvent supplied doesn't have any useful info either. I see: ` { "message": "Script error.", "filename": "", "lineno": 0, "colno": 0, "error": null } ` — huczilla
@huczilla Could you please edit out your "update" and post it as an answer? The question is in an unhealthy state of having no positive answers and yours is as close to correct as there is. — Xan

huczilla huczilla · Accepted Answer · 2015-07-03T21:27:27

5 months after asking this question, I'm now pretty convinced there isn't currently an easy way to global trap/handle Javascript errors occurring in a content script. As such,

I've created a Chrome bug report: window.onerror should contain useful info for thrown error in extension content script. Feel free to chip in with useful comments.
If you need to globally trap content script errors, your best bet is to assume window.onerror is busted for now in content scripts. Instead, wrap all Javascript code in try-catch blocks, which gives you access to useful error information. This is trickier than it sounds, as you have to handle both synchronous code (easy) and asynchronous-callback code (trickier). Take a look at this article for starters, and good luck!