Hello all,
We’re hugely excited to announce version 2.7.0 of JavaScript Tracker and version 0.5.0 of JavaScript Tracker Core. These long-awaited releases bring many new features, including new Optimizely summary context, automatic exception tracking and initial rewriting in TypeScript.
Awesome stuff! Trying out the JS error tracking asap.
We currently have this done via StackTrace.js library + the application_error schema that already excists. Do you guys use a library or is it something you wrote yourself?
Hey @Koen87,
We share your excitement!
No, we don’t use any third-party libraries. We wrote very thin wrapper around JS Error API, it attaches callback to document and sends data as self-describing events.
60% of all the Errors we are currently tracking with the new error tracking all come back with “JS Exception. Browser doesn’t support ErrorEvent API.”. Looking into this it seems most of them come from Mobile (both Safari and Chrome).
I was under the impression that most modern browsers all support the ErrorEvent API? Would it be possible to have an option to not send the event when the above Error shows up?
Hello @Koen87,
Yes, JS Tracker has such functionality. You can filter errors by using predicate function as first argument to enableErrorTracking:
snowplow_name_here('enableErrorTracking', function (errorEvent) {
return !errorEvent.hasOwnProperty('message')
})
Where errorEvent is standard ErrorEvent, you can filter it by other properties.
In fact modern browsers should support error event handler. What exact versions of mobile OSes send these empty exceptions? Do they have anything in other columns (fileName, lineColumn)? Error event handler was not standardized for a long time, therefore for some browsers there could be another ways to track exceptions.
On the other hand if these browsers are not very modern - many exceptions there may be sensible as they likely don’t support other APIs.
Hi @anton, digging up an old post.
We are getting a lot of those “JS Exception. Browser doesn’t support ErrorEvent API.” errors, and from modern browsers. Below are the 5 configurations that generated the most of those errors today so far:
| os_name | br_name | br_version |
|-------------|---------------|--------------|
| Windows 10 | Chrome | 63.0.3239.84 |
| Windows 7 | Chrome | 63.0.3239.84 |
| Mac OS X | Chrome | 63.0.3239.84 |
| Android 4.x | Mobile Safari | 4.0 |
| Windows 10 | Firefox | 57.0 |
The other columns (line_number, stack_trace) are also empty.
Does anybody else experience this? Why would modern browsers generate empty errorEvent object? Googled that question without any luck.
Hello @borismo,
Indeed, this is quite strange. Especially because I believe your statistics closely resembles actual popularity of environments, which makes me think we’re seeing here something browser-independent (but instead specific to your code-base, bug in tracking or initialization problem). But out of curiosity, can I ask you what proportion we’re talking about? Is it 0.5% or 50% of error events?
This behavior and message is result of absence of relevant fields in captured ErrorEvent and I think it is possible to throw an error without corresponding properties. To narrow down source of problem we need to figure out what exact (and how) error occurs without setting these properties. You can find contextsAdder argument from enableErrorTracking especially useful for that. Basically this is a function that receives an raw ErrorEvent and produces an array of contexts that will be sent along with this error event. And you can access any properties of event or browser to send along with tracked error, you can try for example to JSONify the error and send this JSON as a string to inspect after that.
Please let us know about your findings.
Dear @borismo,
I added Snowplow Error Tracker and I faced this problem too. My most errors are “JS Exception. Browser doesn’t support ErrorEvent API”. Did you find any solution for this problem ?
+1 for seeing the same error message. I think for some reason Snowplow JS tracker failed to get all the error information it needs
+1 I’m surprised no one else has posted about this in over a year? Do others have it working?
Before even deploying it to production, I deployed it to a staging environment and my browser (Chrome Windows 10) immediately threw this on the first page view. For what it’s worth, I don’t even see any JS errors in the console. I just see some Chrome warnings about cross-site cookies being deprecated sooner or later.
Hi @jason,
On the surface of it, the root cause appears to be something to do with the API for actually capturing the errors themselves, and its not being supported widely across browsers.
We have an issue open to look into it, but it’s not yet come into focus.
As far as unblocking development of the tracker, the above suggested workaround is to filter out these errors.
Best,
Hi,
This error has surfaced in our tracking and I just want to make sure the suggested fix is still the right approach please, given how old this thread is. I can see that the issue mentioned above is still open.
I’d also like some clarification on the fix itself mentioned in anton’s comment please - the predicate filters errors that don’t have a message property, whereas I’d expect something more like this (without the ! on line 2):
snowplow_name_here('enableErrorTracking', function (errorEvent) {
return errorEvent.hasOwnProperty('message')
})
Any help would be much appreciated!
Thanks.
Hi @af-tomwilkins,
Yes you can still use this technique to ensure that only events fire where the ErrorEvent API is supported.
Your change is correct if you want to filter out errors that don’t have the ‘message’ property. If the filter function returns true then the error event will be tracked.
I think it’s worth pointing out, many of these messages come from the naive implementation in the JavaScript tracker that we will look to improve in coming releases. We currently only check if the message attribute is falsy, and if so then we track this string of "JS Exception. Browser doesn't support ErrorEvent API". The fact you are seeing these events at all suggest there is an error on your site somewhere, the JavaScript tracker has a listener on window error events window.addEventListener('error', function(event) { ... }) but you’ll be seeing this message "JS Exception. Browser doesn't support ErrorEvent API" if there is no message present on the error.
Thanks @PaulBoocock, that’s very helpful! The stack_trace field is always null where the placeholder message appears, and browsing the site it’s seems to correspond to a CORS error (not affecting UX fortunately) which may explain why an error message isn’t present.
I’ll try to fix that before suppressing the error.
Hi @PaulBoocock, I resolved the CORS error I mentioned and unfortunately it’s had no effect on the volume of placeholder error events being recorded.
With no stack trace or error message, I’m struggling to identify the cause. In the Poplin extension, I even see the event being generated without seeing errors in the dev tools console (although I do see warnings relating to Chrome extensions).
Do you know what sort of errors could be causing this? I may end up filtering out placeholder errors as suggested but that feels like a last resort.
Thanks for your help so far.
I wonder if you could perhaps catch the errors yourself in the console and see what we’re dealing with?
Assuming you have time to paste it into Dev Tools before the error fires (or can add this into your site before you load the Snowplow tag?), then you could log out all the errors using the same logic that the Snowplow Tracker uses to send events:
window.addEventListener('error', (errorEvent) => console.log(errorEvent), true);
The variable errorEvent is what the Snowplow Tracker uses to construct the event. In particular we use errorEvent.message, errorEvent.filename, errorEvent.lineno, errorEvent.colno, errorEvent.error.
Maybe logging out the entire errorEvent might shed some light on what is actually throwing the error on your page.
The only other question I have for you, is there a particular browser your are seeing this behaviour on if you look at the data you’ve collected so far? I’m keen to improve this tracking in a future release so I’m eager to get as much info as possible.
Thanks @PaulBoocock, I did try that and strangely enough nothing appears in the console - the only evidence an error occurred is in the Poplin extension.
From the data we’re collecting this doesn’t look to be browser specific, it looks representative of what we’d expect for standard pageviews.
| useragent_family | count |
|---|---|
| Chrome Mobile | 118020 |
| Chrome | 93763 |
| Mobile Safari | 60698 |
| Chrome Mobile WebView | 45347 |
| Mobile Safari UI/WKWebView | 26678 |
| Samsung Internet | 22289 |
| Firefox | 19053 |
| Edge | 16450 |
| Safari | 15006 |
The behaviour I’ve described above has been seen on Windows 10 / Chrome Version 85.0.4183.121.
Wow, thats a lot of these events firing…
How about trying this to get the error event to print in the console?
window.snowplow('enableErrorTracking', function (errorEvent) {
console.log(errorEvent);
return true;
})