Skip to content
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

Debugging polymer apps: stack trace is wacko #307

Closed
johnjbarton opened this issue Oct 4, 2013 · 8 comments
Closed

Debugging polymer apps: stack trace is wacko #307

johnjbarton opened this issue Oct 4, 2013 · 8 comments

Comments

@johnjbarton
Copy link

  1. Install polymer zip file in ./third_party/polymer
    https://github.com/Polymer/polymer/releases/download/v0.0.20131003/polymer-all-v0.0.20131003.zip
  2. Install the attached .html file in ./test/onLoadError.html
  3. Open the .html file in browser,
  4. Open devtools > sources panel > pause on errors (stop-signy thing)
  5. reload.

The stack is mapped to source but the locations make no sense.

polymeronloadstack

@johnjbarton
Copy link
Author

Using polymer.js without the minification the stack is ok. So either the sourcemap is incorrect or devtools is mis-decoding the sourcemap.

onloaderrorpolymerall

@johnjbarton
Copy link
Author

Decoding the sourcemap with https://github.com/mozilla/source-map gives the same result as devtools. I'm surprised but it indicates the map in polymer is incorrect.

@johnjbarton
Copy link
Author

Firefox v25 gives the same result as Chrome devtools, the stack frames are not mapped to correct source lines.

@johnjbarton
Copy link
Author

If I build polymer and use polymer.concat.js, then the sourcemap works. polymer.min.js does not work.

@johnjbarton
Copy link
Author

If I change the gruntfile.js to use
mangle: false,
beautify: true,
in the uglify step, then the sourcemap works.

@dfreedm
Copy link
Member

dfreedm commented Oct 7, 2013

Thanks for the deep analysis!

Mangling should just be a filesize optimization (even better with gzip). I'll see if I can mangle the sourcemap into the right shape, or if we have to live with turning that optimization off.

@johnjbarton
Copy link
Author

Just a suggestion: you might try a different minifier, eg one based on esprima just to see if you can get opt and correctness without understanding the cause.

@dfreedm
Copy link
Member

dfreedm commented Oct 10, 2013

Looks like the root cause is gruntjs/grunt-contrib-uglify#22.

Using banner to include the LICENSE will not update the line numbers in the sourcemap, as the banner is added after that step.

I will work around this by adding the license file as a JS source, and uglify will preserve it with the @license JsDoc tag.

dfreedm added a commit to googlearchive/platform that referenced this issue Oct 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants