Add support for browser extensions code

[burivuhster]

Browser extension's code (e.g. chrome extensions, opera add-ons, firefox add-ons) is executed in a local sandbox environment and it has specific protocol.
E.g. chrome extension's background page may have URL like this:
chrome-extension://ifglblkjlploneiecogcdgejdnpjemom/_generated_background_page.html

To make it possible to use TraceKit inside an extension (especially in raven.js) we need to add special protocols to URL parser regexp.

Protocols are:
chrome-extension:// for Chrome extensions
chrome:// for Firefox add-ons
widget:// for Opera add-ons

So I just add them as a possible protocol values, like http or https.

Also in the Firefox extension's code, for some reason, TraceKit fails with an exception while accessing document.domain property. Mozilla has an opened ticket for this (https://bugzilla.mozilla.org/show_bug.cgi?id=417021)
I've removed this check for document.domain, since loading sources is wrapped with try..catch anyway.

[mattrobenolt]

Why was the domain check removed?

[burivuhster]

I wrote about it in pull request info:
in Firefox extension's code (like chrome://myextension/content/smth.html) there is an issue, so when you try to access document.domain property - ff fails with an exception. And seems that mozilla do not want to fix it https://bugzilla.mozilla.org/show_bug.cgi?id=417021

So this check in TraceKit makes it impossible to use the whole lib in firefox extension's environment.

[burivuhster]

Any update on this?

[mattrobenolt]

Yes, actually. I was looking into extensions yesterday since for most users, it's just noise, but I think we can resolve both use cases here.

Can you package up and send me an extension that raises an exception which Raven is able to capture?

The use case that most complain about is the fact that they get exceptions from within their page from buggle exceptions that I want to filter out by default. Then for cases like you're describing, I'd hide this behavior behind an option, such as captureExtensionExceptions or something.

My problem was being able to reproduce the behavior to write code to handle it either way. :)

[burivuhster]

Sure, I've attached a chrome extension (you can install it by downloading and drag'n'drop crx on the chrome's extension page)
It uses my forks of raven and tracekit.

https://www.dropbox.com/s/py8evwvrier61gb/raven-extension.crx

When you click on the button - it throws an exception, catch it with Raven.captureException and sends to our Sentry. You can monitor this in "Inspect views: _generated_background_page.html" on chorme's extensions page (you need to turn on developer mode).

What about catching exceptions from extensions, when it is not desired – there is nothing to worry about here. Extension's code is executed in separate js-context, and some raven on opened web-page will not catch exceptions from extensions. So it could be a web-page with raven opened in browser and background page of an extension with raven – and they will be completely independent.

So I suppose there will no any side effects, after adding 3 new protocols (widget://, chrome:// and chrome-extension://)

And about document.domain check – there is an option: leave this check for all protocols, except chrome:// (for firefox extensions).

[mattrobenolt]

@burivuhster I'd love to agree with you, but my biggest complaints are errors thrown from what seems, extensions themselves.

Take a look at: https://app.getsentry.com/sentry/javascript/group/6832776/

Maybe that makes more sense to you. I was looking for a way to filter these without actually checking for a string match of the error message.

My hunch is that this is coming from the content script which can get injected into the page and appears to run within the context of that page, but I haven't been able to reproduce on my own.

See: https://code.google.com/p/chromium/issues/detail?id=133373

[burivuhster]

Oh wow. That's a really tricky case :)
I was able to reproduce it. Here is an extension: https://www.dropbox.com/s/py8evwvrier61gb/raven-extension.crx
And steps to reproduce are the following:

1. Enable the extension from the link above
2. Go to some site with window.onerror defined (I've used www.citygrillgroup.ro from your link)
3. Press the button, it will generate exception inside content script, but everything is ok, window.onerror is NOT called
4. Go to extensions page and disable "Raven extension test"
5. Every 5 seconds content script sends message to the background script, and when extension is disabled and content script is still active - we have this bad "Uncaught Error: Error connecting to extension nnmhjnogkbnjkjcdnofaglepbeejcgld" exception, and it is handled by window.onerror.

I think it is possible because although webpage scripts and extension's content scripts executed in different contexts (e.g. global variable defined in one will not be accessible from another), they both look at the same window object. And onerror is a property of this common window object.

I have no idea, why this is not reproducing, while extension is enabled.

Seems you're right, it's a reason to make a flag "captureExtensionErrors" or something.