Closed Bug 1471509 Opened 6 years ago Closed 5 years ago

DevTools Console stack trace does not take into account source maps

Categories

(DevTools :: Console, defect, P2)

61 Branch
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1500963

People

(Reporter: petcuandrei, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

Attached file stack_trace.txt
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180626220124

Steps to reproduce:

I had a stack trace in my web app that uses webpack with source mappings.
I opened DevTools Console.
I clicked the entry
patchForm webpack-internal:///./src/app/connection-management/shared/service-catalog-form/service-catalog-form.component.ts:82:13


Actual results:

I was sent to our transpiled version of the file instead of the source map file


Expected results:

I expected to see the entry pointing to webpack:///src/app/connection-management/shared/service-catalog-form/service-catalog-form.component.ts and clicking it should send me to the TypeScript file, not the JS file the TS file was compiled into.
Component: Untriaged → Console
Product: Firefox → DevTools
Version: 63 Branch → 61 Branch
Would you have a reduced test case (ideally something on glitch) I can test to see where the issue comes from ?
Flags: needinfo?(andreip)
Priority: -- → P2
Blocks: source-maps
https://andreicristianpetcu-ngcli.glitch.me/

If I put a breakpoint in the debugger on the line that throws the error I see the correct file and the correct stack trace.

export class MyNewComponentComponent implements OnInit {

  constructor() { }

  ngOnInit() {
    //breakpoint herer
    throw "Some error for reporting a Firefox DevTools bug https://bugzilla.mozilla.org/show_bug.cgi?id=1471509";
  }

}

But the error in the console is totally unrelated. I expect when I click the error in the console I should go to the place where the exception was thrown.

 ERROR Error: "Some error for reporting a Firefox DevTools bug https://bugzilla.mozilla.org/show_bug.cgi?id=1471509"
viewWrappedDebugErrorhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:36747:15callWithDebugContexthttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:40513:15debugCheckAndUpdateViewhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:40181:12detectChangeshttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:37997:13tickhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33874:58tickhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33874:13_loadComponenthttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33908:9bootstraphttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33850:9_moduleDoBootstraphttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33651:74_moduleDoBootstraphttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33651:13bootstrapModuleFactoryhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33617:21invokehttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2710:17onInvokehttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33117:24invokehttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2709:17runhttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2460:24scheduleResolveOrRejecthttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:3194:29invokeTaskhttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2743:17onInvokeTaskhttps://andreicristianpetcu-ngcli.glitch.me/vendor.js:33108:24invokeTaskhttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2742:17runTaskhttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2510:28drainMicroTaskQueuehttps://andreicristianpetcu-ngcli.glitch.me/polyfills.js:2917:25

Hope this clears a things a bit. Feel free to remix the glitch project :)
Flags: needinfo?(andreip)
Thanks a lot andreip ! This is really helpful.
I looked at your example and debugged it and it seems that Angular wraps thrown Error in try/catch block (see callWithDebugContext) when the view is updated (debugCheckAndUpdateView), do some computation  with the error object and throw it again.
Which means that in the end that you don't get a meaningful stacktrace. Note that it is the same in Chrome (even if the Error object's stacktrace there is sourcemapped, which is not the case in Firefox, but is known https://github.com/devtools-html/debugger.html/issues/6114).

What would you expect to be displayed in the console ?
I expect to see the same stack trace in the console that I see in the debugger. For example here is the stack trace from the debugger (check out the print screen also). I would prefer to see the stack when I click parts of the error messages. Clicking is super important in using a stack trace.

ngOnInit (my-new-component.component.ts#13)
checkAndUpdateDirectiveInline (core.js#9042)
checkAndUpdateNodeInline (core.js#10306)
checkAndUpdateNode (core.js#10268)
debugCheckAndUpdateNode (core.js#10901)
debugCheckDirectivesFn (core.js#10861)
View_AppComponent_0 (AppComponent.html#19)
debugUpdateDirectives (core.js#10853)
checkAndUpdateView (core.js#10250)
callViewAction (core.js#10491)
execComponentViewsAction (core.js#10433)
checkAndUpdateView (core.js#10256)
callWithDebugContext (core.js#11143)
debugCheckAndUpdateView (core.js#10821)
detectChanges (core.js#8637)
tick (core.js#4514)
tick (core.js#4514)
_loadComponent (core.js#4548)
bootstrap (core.js#4490)
_moduleDoBootstrap (core.js#4291)
_moduleDoBootstrap (core.js#4291)
bootstrapModuleFactory (core.js#4257)
invoke (zone.js#388)
onInvoke (core.js#3757)
invoke (zone.js#387)
run (zone.js#138)
scheduleResolveOrReject (zone.js#872)
invokeTask (zone.js#421)
onInvokeTask (core.js#3748)
invokeTask (zone.js#420)
runTask (zone.js#188)
drainMicroTaskQueue (zone.js#595)
Got it. That's good to know since we do plan to use the same component as the debugger in a near future !
Is there an issue I can follow?
Maybe the Inspector dom event tooltip can use it also :D
(In reply to andreip from comment #8)
> Is there an issue I can follow?

There's Bug 1390768
Bug 1390768 made a HUGE improvement for me but it still did not fix the issue I had: I wanted from the stack trace to be able to go back to the source of the bug.

This is my new and improved stack trace:

viewWrappedDebugError 11 Angular	invoke zone.js:388
onInvoke Angular	invoke zone.js:387
run zone.js:138
scheduleResolveOrReject zone.js:872
invokeTask zone.js:421
onInvokeTask Angular	invokeTask zone.js:420
runTask zone.js:188
drainMicroTaskQueue zone.js:595
promise callback*scheduleMicroTask zone.js:578
scheduleTask zone.js:410
scheduleTask zone.js:232
scheduleMicroTask zone.js:252
scheduleResolveOrReject zone.js:862
then zone.js:962
bootstrapModule Angular	ts main.ts:11
Bootstrap 6 Webpack

This is what I would expect:
ngOnInit (my-new-component.component.ts#13)   <-------  THIS IS SUPER IMPORTANT! The actual source of the exception
checkAndUpdateDirectiveInline 7 Angular
View_AppComponent_0 (AppComponent.html#19)
debugUpdateDirectives 15 Angular
invoke (zone.js#388)
onInvoke (core.js#3757)
invoke (zone.js#387)
run (zone.js#138)
scheduleResolveOrReject (zone.js#872)
invokeTask (zone.js#421)
onInvokeTask (core.js#3748)
invokeTask (zone.js#420)
runTask (zone.js#188)
drainMicroTaskQueue (zone.js#595)
Attached image image.png
Hello Andrei,

Your example is nice because I'm seeing some visual glitches that I'll fix :D 

Like I said in Comment 4, the exception is caught by Angular and an error is logged, which messes the actual call stack you'd rather see.

We do handle sourcemap, for example if you add a console.trace in my-new-component.component.ts, you get the following result (see attachment)

I need to check with Angular devs to have their opinion on this
Attached image Correct stacktrace
Hello again Andrei,

I'm going to close this bug as I think we fixed everything we could on our side.
By the way, by checking Angular code I was able to see that they run some check on the thrown object, testing if it's an error object.
So I replaced the line on my-new-component.component.ts ngOnInit by : 

> throw new Error("Some error for reporting a Firefox DevTools bug https://bugzilla.mozilla.org/show_bug.cgi?id=1471509";

And you can see on the screenshot that it does report the error as it should, with the typescript file.

So I think it should cover every case where you don't throw a string on purpose (for example `a.sdfsd.sdfs.sdfsdf` would throw an error).

If it does not cover your case, maybe contact the Angular team and explain them your issue and see how you could fix it.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Sorry for wasting your time Nicolas with such a n00b mistake. I have no reason to throw a string. I have a similar issue in a hugely complicated proprietary project. Somehow the new Error() part got lost in my public example.

✨✨✨✨I replaced it with your suggestion and it is AWESOME!!!!✨✨✨✨

Glad you saw some visual glitches :D
(In reply to andreip from comment #15)
> Sorry for wasting your time Nicolas with such a n00b mistake. I have no
> reason to throw a string. I have a similar issue in a hugely complicated
> proprietary project. Somehow the new Error() part got lost in my public
> example.

No worries at all, it's not a mistake since it's buried in Angular code.

> ✨✨✨✨I replaced it with your suggestion and it is AWESOME!!!!✨✨✨✨

Great to hear!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: