Calling nsIProfiler.StartProfiler from the error console causes stack-trace-collector.js to print an error: NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] stack-trace-collector.js:90
Categories
(DevTools :: Console, defect, P2)
Tracking
(firefox70 fixed)
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: mstange, Assigned: bhackett1024)
Details
Attachments
(1 file)
20190711095112
Steps to reproduce:
- Open the browser console (with devtools.chrome.enabled = true).
- Paste and run the following:
Services.profiler.StartProfiler(1000000, 1, ["js", "stackwalk", "threads"], ["GeckoMain", "Compositor"]);
Expected results:
Only undefined
and no error should appear on the error console.
Actual results:
After printing undefined
, the error console shows the following error:
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] stack-trace-collector.js:90
It seems like stack-trace-collector.js is part of the network monitor. I am very confused as to why the network monitor is involved here at all.
Comment 1•5 years ago
|
||
It seems like stack-trace-collector.js is part of the network monitor. I am very confused as to why the network monitor is involved here at all.
The console also listens for network requests and show them to the user (if the Request
or XHR
filters are enabled).
This observer is responsible for saving the stacktrace that led to a network call, so we can display it in the "Stacktrace" panel displayed in the network detail.
This might be a regression from Bug 1392411. Brian, could you have a look please?
Updated•5 years ago
|
Comment 2•5 years ago
|
||
erf, forgot to mention how we could have network involved here. My guess is that since we support stacktrace for websocket connections now, maybe the DevTools websocket connection triggers this code and the subsequent error (just a guess, I'm not sure)
Assignee | ||
Comment 3•5 years ago
|
||
These events can come both for websocket channels and for http channels when the main thread stack isn't useful (mainly for channels opened by workers). We expect the channel to be either an nsIHttpChannel or an nsIWebSocketChannel, but in this case it is a file channel which was opened by a worker thread. It seems best to catch the exception thrown by QueryInterface and exit the handler if the channel doesn't have an interface we're interested in.
Assignee | ||
Comment 4•5 years ago
|
||
Pushed by bhackett@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/28f3f7e05e62 Ignore alternate stacks for unknown kinds of channels, r=ochameau.
Comment 6•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•