JavaScript Error Reports - missing source, line and column number

bug
1

I’m seeing the source, line and column number missing from most of the JavaScript error reports

Obviously these may either indicate an actual problem / incompatibility with a device.

Here is a sample:

Pasted image831×250 14.7 KB

Each of these is a different User Agent / browser:

  • Mozilla/5.0 (Linux; Android 4.4.2; SM-N9005 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.93 Mobile Safari/537.36
  • Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko/20100101 Firefox/12.0
  • Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53
  • Mozilla/5.0 (Android; Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
  • Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0
  • Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 620; Vodafone) like Gecko

I understand that some of these may not all be “supported” browsers.

I was thinking maybe something obvious is broken in the capture of the source, line and column number code.

1 Like
2

These simply need to be suppressed.

I went ahead and checked in this regex which should do it, though it might need some refinement

(?m)\AScript error\..*?Line: 0.*?Column: 0

That gets the zero cases that I see in my logs of the form

Script error.
Url: 
Line: 0
Column: 0
Window Location: http://discourse.codinghorror.com/t/the-god-login/2924/19

I’ll do another one for completely empty. Can you paste the raw text in please?

3

Aha I think I see one:

Url: 
Line: 
Column: 
Window Location: http://discourse.codinghorror.com/faq

Will do that in a bit

4

@codinghorror could I ask your reasoning behind this?
Is it that there is never a way of getting the source file / line numbers from these browsers?

If this is the case perhaps we should still keep some kind of count of them to ensure error captures don’t suddenly spike and us not be aware of it.

EDIT: In terms of a regex - this is a more likely fit:

\AUrl:\s+Line:\s+Column:\s+Window Location:\s+
5

I think this regex is better:

/(?m)\A(Script error\.| |)\nUrl: [^\n ]*\nLine: 0?\nColumn: 0?\n/m

Submitted it here.

6

My intention was always just to collapse similar errors and retain counts, have not had a chance to do so yet, this is a stop gap

3 Likes
7

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.

Anything with

Line: 0
Column: 0

or

Line: 
Column:

Is quite useless. I updated to

(?m).*?Line: (?:\D|0).*?Column: (?:\D|0)

and that works on all cases in the errors I have in my log at discourse.codinghorror.com at least.

2 Likes
8

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

  1. Set Discourse instance to “Read-Only” mode
  2. Open Chrome to topic page
  3. Open debug console Ctrl + Shift + i
  4. Copy this line onto clipboard
    window.onerror = function(m, u, l, c, errorObj) { console.log(m, u, l, c, errorObj, errorObj.stack); }
  5. Refresh page
  6. Wait for page to load
  7. 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:
https://github.com/discourse/logster/blob/bbd1a7ae11ad10c7961092eb085439dbeab79e0b/vendor/assets/javascripts/logster.js.erb#L10

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

###Actual Output

 undefined null null null Object {readyState: 4, getResponseHeader: function, getAllResponseHeaders: undefined

Note the source, line and column numbers are null.

###Explanation

Note that the object output is from the Timing call here:
https://github.com/discourse/discourse/blob/f66c39c63bfa57318f742b672b02a02ab18b68a3/app/assets/javascripts/discourse/lib/screen_track.js#L123

Using the Ajax call here:
https://github.com/discourse/discourse/blob/271374a8c62b247d826f8bdfc648da8f36dc8618/app/assets/javascripts/discourse/mixins/ajax.js#L43

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.

3 Likes
9

I also checked and all these browsers have this problem in my logs:

  • Chrome 39 - Windows XP
  • Chrome 39 - Linux - Sony Xperia Z3
  • Firefox/35.0 - Windows XP
  • Firefox/35.0 - Windows 7
  • Safari - iOS 8.1.2 (iPad)
  • Safari - iOS 8.1.2 (iPhone)
  • Chrome 39 - Samsung GALAXY Note 3 - Android 4.2.2
  • Chrome 39 - Windows 8.1
  • Chrome 28 - Samsung Galaxy S4 (GT-I9505)
  • Chrome 37 (Amazon Silk) - Kindle Fire HD - Android 4.0.3
  • Firefox 34.0 - Windows 7
  • Chrome 39 - Sony XPERIA™ Z2 Tablet
  • IE9 - Windows Vista
  • Firefox 35 - Windows XP
  • Firefox 35 - Windows 8.1
  • IE11 - Windows 7
  • Safari - iOS 6.1 (iPhone)
  • Chrome 28 - Samsung Galaxy S5 - Android 4.2.2
10

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?

11

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.

1 Like
12

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.

13

Wouldn’t you rather not suppress for now so help identify the existence of real errors / incorrectly coded things?

If it’s then proven to just be a browser issue and not some coding error then suppress it?

14

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.

15

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?

16

I’m saying putting Discourse into Read-Only is one way of causing these errors…

and yes the AJAX calls do fail with 405’s I believe.

… I believe in this case (read-only etc) it’s not a browser glitch and is a coding error.

17

We generally suppress client JS errors that lack all line and column info now.