Closed Bug 1565343 Opened 5 years ago Closed 5 years ago

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)

defect

Tracking

(firefox70 fixed)

RESOLVED FIXED
Firefox 70
Tracking Status
firefox70 --- fixed

People

(Reporter: mstange, Assigned: bhackett1024)

Details

Attachments

(1 file)

20190711095112

Steps to reproduce:

  1. Open the browser console (with devtools.chrome.enabled = true).
  2. 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.

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?

Flags: needinfo?(bhackett1024)
Priority: -- → P2

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)

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.

Flags: needinfo?(bhackett1024)
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/28f3f7e05e62
Ignore alternate stacks for unknown kinds of channels, r=ochameau.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Assignee: nobody → bhackett1024
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: