Still, the useless client submitted JavaScript errors should be removed as noise. Maybe they have a malfunctioning browser, maybe they are browsing with IE7, who knows.
I believe I have found the cause of these error reports missing line numbers.
I could be wrong - but I thought I would share as I currently I debugging in production and source and line numbers are off a bit…
Not quite the root cause - but I can cause it in Google Chrome 39 dependably.
I believe that when an AJAX call fails for whatever reason we are seeing these JavaScript errors with no source, line number or column number.
###Steps to reproduce
Set Discourse instance to “Read-Only” mode
Open Chrome to topic page
Open debug console Ctrl + Shift + i
Copy this line onto clipboard window.onerror = function(m, u, l, c, errorObj) { console.log(m, u, l, c, errorObj, errorObj.stack); }
Refresh page
Wait for page to load
As soon as it seems complete Paste and Execute the line copied to the clipboard.
Note that all we have really done here is replace this function:
With one that will allow Chrome to help us find the source of the error.
And if you were using un-minified sources you could just as easy use window.onerror = null to get better debugging in Chrome.
###Expected Output
Lines to be output including line numbers
Note that the object output is from the Timing call here:
Using the Ajax call here:
So to repeat: I believe that when an AJAX call fails for whatever reason we are seeing these JavaScript errors with no source, line number or column number.
I’m not just thinking the timing AJAX calls have this issue - perhaps others do too?
Until this is proven true or false I believe suppression is perhaps the wrong thing to do and perhaps indicative of an actual problem existing.
Feel free to call me crazy, slap me about and tell me I’m wrong.
I do not agree @deanmarktaylor. Looking at the logs on meta they are full of exactly this:
HTTP_HOST: meta.discourse.org
REQUEST_URI: /logs/report_js_error
REQUEST_METHOD: POST
HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
HTTP_ACCEPT: */*
HTTP_REFERER: https://meta.discourse.org/t/nocaptcha-support/24107/1
HTTP_X_FORWARDED_FOR: 70.117.105.168, 10.0.0.202
HTTP_X_REAL_IP: 10.0.0.202
params:
url:
line:
column:
window_location: https://meta.discourse.org/t/nocaptcha-support/24107/1
Hundreds of these, just like this. Zero backtrace, zero context, just a bunch of crying wolf with no information whatsoever.
And crying wolf is extremely harmful. It devalues any real substantive errors you might find in logs when they are cluttered with hundreds of useless noise entries, submitted by browser clients for who knows why.
I do not find it particularly illuminating to have a new “error” log entry every time a browser client HTTP ajax request fails… do you?
I’m saying that the error capture is broken because of the overrides and implementation of error handling for Discourse AJAX handling or some other element related to it.
The error might not even get to sending to the logs if it was handled correctly on the client.
EDIT: Somehow the promise / error object is getting pushed to onerror incorrectly instead of the correct error detail.
That may be, and improvements in this area are welcome, but client “errors” without a line number or any useful accompanying information are not helpful to ever record. This will continue to be true now, and in the future, whether failed HTTP JavaScript call “errors” are handled better or not.
I trust real user reports (even second hand or anecdotal reports) much, much more than random local browser JavaScript freakouts that get recorded on the server.
Putting discussion about error suppression vs. error handling aside @DeanMarkTaylor are you saying you think it’s Discourse being in Read Only mode that is causing the AJAX FAILs and not a browser glitch?
