Console should use the new API for tracking promises that are rejected and not handled
Categories
(DevTools :: Console, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: fitzgen, Unassigned)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [polish-backlog][difficulty=medium])
New API implemented in bug 1083361. Note that this API is not GC-sensitive (a very good thing), but requires a little more finesse on the devtools side. It is essentially an event stream of "this promise was rejected and unhandled" and "nevermind, it got handled later" events. This means we will need a way of either hiding, striking out, or graying out old console messages.
|
||
Comment 1•9 years ago
|
||
Jeff - I took a stab at prioritizing. What do you think?
|
||
Comment 2•9 years ago
|
||
(In reply to Joe Walker [:jwalker] (overloaded - needinfo me or ping on irc) from comment #1) > Jeff - I took a stab at prioritizing. What do you think? Sounds good. WHy is this a devedition-40 bug? It seems to me there won't be any user impact for this ( unless I'm reading it wrong ) without additional console frontend work. FYI - when referencing me in bugzilla always type ':canuckistani' with the ':' otherwise you'll find an older personal account and I won't see this right away, it gets buried in Inbox.
|
Reporter | |
Comment 3•9 years ago
|
||
User impact is more reliable promise rejection reporting. Don't have to wait for a GC anymore (sometimes many seconds) -- get feedback immediately.
|
|
||
Comment 4•9 years ago
|
||
(In reply to Nick Fitzgerald [:fitzgen] from comment #3) > User impact is more reliable promise rejection reporting. Don't have to wait > for a GC anymore (sometimes many seconds) -- get feedback immediately. Got it - thanks.
|
|
||
Updated•9 years ago
|
|
||
Comment 5•9 years ago
|
||
Also, note that, in my quest to ensure that javascript stacks are always displayed in the console, I found that Promise unhandled reports are still missing stacks. That's because the old reprecated way to report it from C++ here: http://mxr.mozilla.org/mozilla-central/source/dom/promise/Promise.cpp#1187 uses AsyncErrorReporter, which doesn't support passing stack. So, ideally, we would do this bug and also address the stack being missing!
|
||
Updated•6 years ago
|
|
|
||
Comment 6•6 years ago
|
||
Here is some links to bugs that are relevant when discussing about stacks of error messages.
A significant work has been done in bug 814497 in order to ensure passing stacks up to the console actor.
This led to interesting-to-be-aware-of leak in bug 1254230.
And the thing is that from the day we landed this work, we knew that stacks are missing for every message that is not bound to a window/document. So we expected to miss stacks for everything coming from a JSM, XPCOM, Sandbox, ...
Bug 1237904 has been filed to track that, but has been closed by mistake at the end of fxos.
jryans wanted to finally tackle that but never got to it.
The last time we discussed about all that was in bug 1452798 as sentry was missing most error traces... Almost everything but browser.xul error messages I imagine.
|
||
Updated•6 years ago
|
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
(In reply to Alexandre Poirot [:ochameau] from comment #5)
I found that Promise unhandled reports are still missing stacks.
That's because the old reprecated way to report it from C++ here:
http://mxr.mozilla.org/mozilla-central/source/dom/promise/Promise.cpp#1187
uses AsyncErrorReporter, which doesn't support passing stack.
https://phabricator.services.mozilla.com/D44608 proposes adding stack support to AsyncErrorReporter.
|
||
Comment 8•5 years ago
|
||
Switching to enhancements as I noticed this when creating demos. Not having stacks for errors makes them really confusing and not helpful for devs: https://firefox-devtools-unhanded-rejection-promise.glitch.me/
|
|
||
Updated•2 years ago
|
Description
•