exceptions logged by Meteor code (not uncaught exceptions) don't use source maps for stack trace

[philcockfield]

_1 Upvote_ There was a time not very long ago when clicking on a link within the stack trace of a meteor generated error in Chrome would open up the corresponding file in the Sources tab in dev tools (in our case coffeescript).

Since Chrome updated to around version 40.x.x these links no longer open up the Sources window in Chrome dev-tools, rather they open up a new tab with the raw JS in it. The boilerplate header includes a reference to turning the feature on (which it is):

//////////////////////////////////////////////////////////////////////////
//                                                                      //
// This is a generated file. You can view the original                  //
// source in your browser if your browser supports source maps.         //
//                                                                      //
// If you are using Chrome, open the Developer Tools and click the gear //
// icon in its lower right corner. In the General Settings panel, turn  //
// on 'Enable source maps'.                                             //
//                                                                      //
//////////////////////////////////////////////////////////////////////////

Multiple people on the Respondly team are having the problem - so I think think something has definitely broken here. Not sure if it's from the Chrome side, or the Meteor side.

Is there a fix for this? Or is this a bug? Thanks!

[glasser]

I think this is a distinction between errors that make it all the way up to the top level in Chrome itself, and errors that are caught by some layer and printed. Are you sure you've actually seen the same user code work both ways?

[lukejagodzinski]

I've noticed the same problem with Chrome. For me it's definitely something on Google side. I think that this problem only occurs on my Mac, not on Linux machine (but maybe I'm wrong).

[PeppeL-G]

I've been having problem with source maps (js -> coffee) lately in Chrome too, and I'm using Linux (Lubuntu). Don't know about glasser's comment, though.

[philcockfield]

@glasser yes, you're right, there is a distinction between those two types of errors. One's that throw successfully right into the console do open the source document for me. Eg: this works

The printed errors definitely used to work In Chrome pre version 40. I lived and breathed on these opening up the source at the right place - and so noticed sharply when it stopped [ thanks Chrome! :)].

I figured it would fix itself in a Chrome update since then, but hasn't - so I thought I'd ask. Thanks.

[For reference I'm on OSX].

[glasser]

OK. Can you confirm that it's definitely a Chrome change and not a Meteor change that made this change? ie, can you try using old versions of Meteor and see if it shows the traces for you? (And try using old Chrome versions too if that's actually a feasible thing?)

[philcockfield]

@glasser - yes, I'll check that out on an earlier version of Meteor. Have tried installing an earlier version of Chrome, but that's damn near impossible.

Will report back.

[hharnisc]

@glasser @philcockfield - here's a self contained example. Breaking something inside of a Template.instance.rendered callback causes the issue.

The example app:

https://github.com/hharnisc/meteor-coffeescript-source-map-repro

The breaking line:

https://github.com/hharnisc/meteor-coffeescript-source-map-repro/blob/master/coffeescript-source-map-repro/break-it.coffee#L6

[glasser]

@hharnisc OK, but I'm still trying to figure out if this is a regression or not. My impression had been that these ones never worked; @philcockfield disagrees. If it really is something that used to work, it should be straightforward to find out when we (or Chrome?) broke it.

[hharnisc]

@glasser Browserling with Chrome v39 - and the isolated sample app deployed to http://source-map-bug.meteor.com

https://www.browserling.com/browse/chrome/39/http%3A%2F%2Fsource-map-bug.meteor.com%2F

Opening up the JS console and clicking a source file (its the compiled JS rather than the coffeescript) opens the in the Source tab -- which at least let you set debug points and pointed to the offending line of code.

[philcockfield]

@hharnisc - thanks Harrison. Perhaps it was Chrome doing some magic and showing the Coffee from those links after it found the JS. But to be sure, seeing the coffeescript doesn't matter. Just getting back to seeing the underlying Javascript in the source window is all that's important to be debug an app.

[funkyeah]

Can confirm I am seeing the same issue. Actually filed a stackoverflow.

Not sure if its a regression or not, and seems that hharnisc is already on that path. For what its worth I'm running Chrome 41.0.2272.35 beta (64-bit) on Ubuntu 14.04

[hharnisc]

Yep that looks like the same issue. Upvoted that on SO. Slows down development quite a bit at times.

[mizzao]

Ugh, just ran into this as well. I'm not even sure how to go to a particular line in the new tab that Chrome opens.

Definitely worked before without a change in Meteor - 1.0.3.1 and broke when Chrome updated.

Did you guys find any solutions for this?

[Slava]

+1, ran into this during app week. Found this issue on chromium bug tracker https://code.google.com/p/chromium/issues/detail?id=376409

[Slava]

Phil pointed out to me that the linked Chrome issue is really old. I am not sure now if it is supposed to work at all.

This is how we could workaround the problem:

• don't print the stack, instead re-throw the exception in a separate timeout (uncatchable, maybe provide an argument to handle errors)
• don't print the stack, re-throw the exception in the same stack (breaks Tracker, is catchable)
• print stack with some processing like this one https://github.com/novocaine/sourcemapped-stacktrace

[avital]

Yeah, maybe setTimeout(function () { throw e; }) just does the right thing

[Slava]

I found out that just printing the stacktrace alone makes the output correctly sourcemapped: console.log(err.stack), but doing so after printing some string breaks it console.log("something", err.stack).

[Slava]

But none of that works correctly in FF 36. Same in Safari. It is like this sourcemap support was built only in Chrome.

[philcockfield]

@Slava @avital - thanks so much for dealing to this. It's going to be a huge productivity boost to get this debugging workflow back again!

[IstoraMandiri]

I've done a bit of research and the linking is 'fixed' in Chrome Canary -- although it still doesn't do proper source mapping unless the stack is passed as the only argument; it just goes to the actual javascript.

The above commit fixes the stack trace linking and implements proper source mapping this by passing the stack trace as the only argument if it exists.

Let me know if this is worth sending a PR on.

[glasser]

@Slava It sounds like @hitchcott 's commit is similar to what you're doing in #3822?

[Slava]

@glasser yeah, but I am afraid his commit breaks message reporting on safari and FF?

[IstoraMandiri]

I did a couple of tests in some browsers, forcing an error by doing:

Template.main.helpers
  something: -> missing.item

The tracker-erros branch seems to behave the same as devel for the above test -- could be that @salva and I have patched the same issue in different places. Here are my findings using the above test:

tracker-errors + devel
Chrome 40/41 (current) - Links available, but do not map correctly to JS or CS (as described in thread)
Chrome 43 (canary) - Links works to JS, no CoffeeScript mapping
Safari 7.1.3 - Similar behaviour as Chrome 40
FF 36 - 100 line stack trace string, no linking

IstoraMandiri@213f2af behaviour
Chrome 40/41 (current) - Correct CoffeeScript Mapping
Chrome 43 (canary) - Correct CoffeeScript Mapping (see below)
Safari 7.1.3 - Same behaviour as before
FF 36 - Same behaviour as before

As for the commit, I imagine that it's only covering some cases of the exception. Tried to deal with it in _debug.js, but I can't find a reliable way of detecting. It appears that this code has stopped working on newer releases of chrome.

Edit: Chrome pushed v41 this morning

[Slava]

Right, I would to make it bearable in all browsers as possible (admittedly, in Safari and FF the behavior is quite terrible no matter what we do, but at least we can print a mapped stack-trace).

I am pushing updates to my PR, a new feature there is the onError callback, which I wish will help to debug most of the problems. (For example, you can put a breakpoint there.)

[hwillson]

This is no longer an issue with modern versions of Meteor (verified with Meteor 1.5.1) and modern browsers. Closing - thanks!