New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
philcockfield opened this Issue Feb 6, 2015 · 25 comments

Comments

Projects
None yet
@philcockfield

philcockfield commented Feb 6, 2015

_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).

console-error

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

This comment has been minimized.

Member

glasser commented Feb 6, 2015

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

This comment has been minimized.

lukejagodzinski commented Feb 6, 2015

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

This comment has been minimized.

PeppeL-G commented Feb 6, 2015

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

This comment has been minimized.

philcockfield commented Feb 10, 2015

@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

image

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

This comment has been minimized.

Member

glasser commented Feb 10, 2015

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?)

@glasser glasser changed the title from Source-maps error links broken in Chrome. to exceptions logged by Meteor code (not uncaught exceptions) don't use source maps for stack trace Feb 10, 2015

@philcockfield

This comment has been minimized.

philcockfield commented Feb 11, 2015

@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

This comment has been minimized.

hharnisc commented Feb 12, 2015

@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

This comment has been minimized.

Member

glasser commented Feb 12, 2015

@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

This comment has been minimized.

hharnisc commented Feb 12, 2015

@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

This comment has been minimized.

philcockfield commented Feb 12, 2015

@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

This comment has been minimized.

funkyeah commented Feb 24, 2015

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

This comment has been minimized.

hharnisc commented Feb 24, 2015

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

@mizzao

This comment has been minimized.

Contributor

mizzao commented Feb 24, 2015

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

This comment has been minimized.

Member

Slava commented Feb 24, 2015

+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

This comment has been minimized.

Member

Slava commented Feb 25, 2015

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

This comment has been minimized.

Contributor

avital commented Feb 25, 2015

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

@Slava

This comment has been minimized.

Member

Slava commented Feb 26, 2015

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

This comment has been minimized.

Member

Slava commented Feb 26, 2015

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

Slava added a commit that referenced this issue Feb 26, 2015

Tweaks to error reporting in Tracker.
- Allow passing an onError callback to Tracker.autorun.
- Workaround the issue described in #3655 by logging parts of error message
  separately.
@philcockfield

This comment has been minimized.

philcockfield commented Feb 26, 2015

@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!

@hitchcott

This comment has been minimized.

hitchcott commented Mar 3, 2015

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

This comment has been minimized.

Member

glasser commented Mar 3, 2015

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

@Slava

This comment has been minimized.

Member

Slava commented Mar 3, 2015

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

@hitchcott

This comment has been minimized.

hitchcott commented Mar 4, 2015

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

hitchcott@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

Correct CoffeeScript Mapping

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

This comment has been minimized.

Member

Slava commented Mar 17, 2015

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.)

Slava added a commit that referenced this issue Mar 17, 2015

Tweaks to error reporting in Tracker.
- Allow passing an onError callback to Tracker.autorun.
- Workaround the issue described in #3655 by logging parts of error message
  separately.
@hwillson

This comment has been minimized.

Member

hwillson commented Aug 17, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment