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

Use sourcemaps to revert stacktrace in extension #995

Closed
wants to merge 6 commits into from

Conversation

wardpeet
Copy link
Collaborator

@wardpeet wardpeet commented Nov 21, 2016

Should fix #972, downside is that I had to fix an issue with browserify sourcemaps inside novocaine/sourcemapped-stacktrace#19

perhaps you know of another library? (didn't want to write it myself)

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps you know of another library

I don't, but maybe @addyosmani or @paulirish (when he's back) know of one or a simpler way to do this?

@@ -23,5 +23,8 @@
"gulp-zip": "^3.2.0",
"run-sequence": "^1.1.5",
"through2": "^2.0.1"
},
"dependencies": {
"sourcemapped-stacktrace": "^1.1.3"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be in devDependencies

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i require it inside browserify doesn't that make it a dependency?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think in practical terms it doesnt matter, but i agree that semantically it fits in deps more than devDeps

@@ -157,7 +166,10 @@ document.addEventListener('DOMContentLoaded', _ => {

if (!multipleTabs && !debuggerExists) {
feedbackEl.className = 'feedback-error';
feedbackEl.appendChild(buildReportErrorLink(err));
buildReportErrorLink(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally we'd want the error passed to background.console.error below to also be source mapped

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done :)

const body = '&body=' + encodeURI(qsBody);
return new Promise(resolve => {
sourcemapStacktrace.mapStackTrace(err.stack, function(mapped) {
qsBody += '**Stack Trace**:\n ```' + mapped.join('\n') + '```';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will need to rebase this after #992

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done :)

Copy link
Member

@paulirish paulirish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't know of a better library or simpler way to do this, myself. (unless we use devtools frontend for the same resolution, which won't be very fun IMO)

this seems generally on point tho

@@ -23,5 +23,8 @@
"gulp-zip": "^3.2.0",
"run-sequence": "^1.1.5",
"through2": "^2.0.1"
},
"dependencies": {
"sourcemapped-stacktrace": "^1.1.3"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think in practical terms it doesnt matter, but i agree that semantically it fits in deps more than devDeps

@@ -23,5 +23,8 @@
"gulp-zip": "^3.2.0",
"run-sequence": "^1.1.5",
"through2": "^2.0.1"
},
"dependencies": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to wait for your PR to land upstream first?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if necessary I can publish the github repo under my name in npm repo until the pr is accepted

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@paulirish PR got accepted ^^

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in that case you'll want to bump to 1.1.4 ;)

@@ -122,6 +126,21 @@ document.addEventListener('DOMContentLoaded', _ => {
return listItem;
}

function showError(err, message, includeReportLink) {
sourcemapStacktrace.mapStackTrace(err.stack, stackWithSourcemaps => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we do a try/catch around the mapStackTrace call? I want to make sure we gracefully degrade and still show the error reporting stuff even if the sourcemap resolution fails.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to test my new approach :)

@wardpeet
Copy link
Collaborator Author

wardpeet commented Dec 2, 2016

Background.js looks like this
image

Issue looks like this
image

@paulirish
Copy link
Member

Tried it out when I was hitting some bugs. Some examples of this PR in action:

before and after - exception 1

image
image

before and after - exception 2

image
image

@paulirish
Copy link
Member

I like the added benefit this PR gives our error stack traces. The impact on our bundle size for adding this new module is ~90kb which is similar to the jszip that we removed.

However on the other hand, this means including sourcemaps for our entire bundle which takes the filesize from 2.4mb to 6.5mb.

@wardpeet
Copy link
Collaborator Author

wardpeet commented Dec 3, 2016

mmh I don't think we can fix the sourcemap issue but I might be able to pick relevant pieces of the library and put them in lighthouse but probably won't save that much because I will still be dependent on the sourcemap dependency

@wardpeet
Copy link
Collaborator Author

wardpeet commented Dec 9, 2016

@paulirish don't forget we are also removing url and whatwg-url from the extension.

@wardpeet
Copy link
Collaborator Author

@paulirish I did a new check with a rebase of master and got the following results
Master is still 2.4MB
My branch is 6,0MB

Is it that bad? We could also do a better issue tracking and use the report viewer to convert stacktraces so the extension stays 2MB and the heavy lifting is done by the viewer but than we need to build a small ui for it.

@brendankenny
Copy link
Member

should we close this? Looks like the impact on code size would be too great? It seems like it hasn't been too hard to backtrack from extension strack traces to original source code

@wardpeet
Copy link
Collaborator Author

@brendankenny yeah think closing is ok :)

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

Successfully merging this pull request may close these issues.

Create and ship source map for better extension stack traces
3 participants