Turn off capture by default

[dcramer]

Thoughts on turning it off by default?

I want to include TraceKit as part of Raven (https://github.com/getsentry/raven-js), but I'm hoping to deprecate hooking window.onerror for better methods (such as binding window.setTimeout, jQuery.fn.ready, etc.)

[devinrhode2]

Just one line of code to turn off:

TraceKit.collectWindowErrors = false;

[occ]

Just a side note: While .collectWindowErrors disables notifications, we still attach our own window.onerror handler. We should improve that.

My opinion is that the default configuration should still have the window.onerror handler, as most applications will expect TraceKit to handle errors and report to them. It's just my opinion though.

[devinrhode2]

Yeah we should have a function like jQuery.noConflict(), which is actually pretty easy to implement and I could get to next time I'm working on some commits.

The hardest thing is: what to name it?

Perhaps TraceKit.noWindowOnError() or TraceKit.window.onerror.undo() or EVEN COOLER window.onerror.restorePrevious()

[devinrhode2]

We collect window errors by default, but I proposed a new handler here in #21 (Could someone close this issue?)

[niemyjski]

@devinrhode2 I'm helping maintain TraceKit upstream.. If you want to recreate this issue in the master (https://github.com/csnover/TraceKit). I'd be open to taking a closer look into this.

[niemyjski]

@dcramer what are your thoughts on this? I think this would be a good thing to have, esp for unit tests.

[dcramer]

TraceKit is tbh kind of a mess to use as a thirdparty as it tries to do too much. It explicitly states goals that are counter to what the API exposes:

Attempts to create stack traces for unhandled JavaScript exceptions in all major browsers.

What it actually does is "attempts to collect errors for you and send them to a subscriber". I dont want that. I want a library which understands the complexities of error objects and stacktraces, and doesnt try to prescribe its own system for grabbing them.

[niemyjski]

@dcramer, I completely and 100% agree... My goals is to get a solid tested release that is bug free and works with modern engines... After this has been done... I'd like to split all of the integrations out and have separate builds with those integrations (plugins)... This would allow you to use this on node or xyz with minimal size and buy into what you need. For example why should we be including jquery support if you aren't using jquery...

But we need to be smart about this... Because we have a lot of people using tracekit and I don't want to break anyone.. I want to be able to drop in a plugin and it just works as before..

Will you help me work towards this in the main repo?

[niemyjski]

@dcramer I've been trying to talk with someone from raven about bringing in their changes: https://github.com/csnover/TraceKit/issues/14 can you add me on skype: blake.niemyjski

[dcramer]

You can pull them in but we don't have the resources to help with this. The only reason we used tracekit in the first place was its seemingly good ability to structure stacktraces. We don't actively work on that part of the code as its effectively solved for us.

[niemyjski]

@dcramer I had questions on why you made a few changes is why I was hoping to meet up / talk with someone.

[niemyjski]

Also your regexes are slightly different from what we have, you might want to compare them as I think the current one of ours is correct.