This seems to be fixed, probably by bug 1392411. Re-open if chrome stacks still appear.

Sorry, not fixed yet!

STR:

1. Open the Network panel on this page
2. Reload the page
3. Click the request for the document
4. Switch to the Stack Trace tab

You'll see something like this:

receiveMessage/< resource:///actors/BrowserTabChild.jsm:98:26
wrapHandlingUserInput resource://gre/modules/E10SUtils.jsm:837:7
receiveMessage resource:///actors/BrowserTabChild.jsm:95:21

I've tested this in Nightly 72.0a1 (2019-11-04).

In the case of a user initiated request or one only containing stack frames of chrome scripts, I would expect the Stack Trace tab not to be displayed at all.
Having said that, in the Browser Toolbox this info might still be useful.

Sebastian

I can reproduce the problem on my machine too (Win10, Nightly).

@Brian, could you please look at this.

Thanks,
Honza

Honza, Initiator column will put this front and center. For the non-browser-toolbox case, could we test if a stack looks internal and discard it if it does?

I am no longer able to reproduce the problem using STR from comment #5 (there is no Stack Trace tab).
Sebastian, can you?

Honza

Still occurs for me.

Load https://platform-status.mozilla.org/. For https://platform-status.mozilla.org/images/favicon.ico I get:

load
resource:///modules/FaviconLoader.jsm:165:20
load
resource:///modules/FaviconLoader.jsm:557:70
loadIcons
resource:///modules/FaviconLoader.jsm:633:26
onPageShow
resource:///modules/FaviconLoader.jsm:670:12
onHeadParsed
resource:///actors/LinkHandlerChild.jsm:60:24
handleEvent
resource:///actors/LinkHandlerChild.jsm:175:21

For reference, the Stack Trace tab is not shown for the main document request anymore since bug 1595637 got fixed (according to moz-regression).

But, as Harald already pointed out, the issue can still be reproduced on other requests.

In the case of a user initiated request or one only containing stack frames of chrome scripts, I would expect the Stack Trace tab not to be displayed at all.
Having said that, in the Browser Toolbox this info might still be useful.

Actually, I believe displaying chrome frames should depend on the option Show Gecko platform data, which obviously got introduced for the JS Profiler, though also fits for this case, in my opinion.

Sebastian

Thanks!

Some pointers to the code base:

1. The Stack Trace panel is rendered here:
   https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/client/netmonitor/src/components/StackTracePanel.js#67

2. It's using StackTrace component that is implemented here
   https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/client/shared/components/StackTrace.js#37

3. The stack-trace is collected on the backend here
   https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/server/actors/network-monitor/stack-trace-collector.js#114

4. We could peel off the chrome frame on the backend to safe a bit on RDP traffic but, also depends whether we want to support that Show Gecko platform data pref.

Here is an existing helper implemented for the Console panel. It isn't handling all of the chrome frames but, could be adapted:
https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/server/actors/webconsole/utils.js#173-214

@Nicolas: can you provide some info about how the helper could be improved?

Honza

I think we could have another helper, which would do a similar job, but that would filter out all the frames that starts with resource:// or chrome:// ? (maybe we should be more thoughtful on this for webextension? not sure

Thanks Nicolas!
Honza

Should the helper function be implemented in the StackTrace class or in StackTraceCollector itself?

We should peel off the chrome frames directly in the StackTraceCollector (and send to the client only what's needed) but, want tot keep these frames within the Browser Toolbox Network panel. Nicolas, do we have a way to check out whether the Network panel (and it's backend) is instantiated in the regular or Browser Toolbox?

Honza

Is someone working on this bug? I want to try it

Assigned to you, thanks for the help!

Honza

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #15)

We should peel off the chrome frames directly in the StackTraceCollector (and send to the client only what's needed) but, want tot keep these frames within the Browser Toolbox Network panel. Nicolas, do we have a way to check out whether the Network panel (and it's backend) is instantiated in the regular or Browser Toolbox?

We have this function on the toolbox devtools/client/framework/toolbox.js#606-608

Hi Maria, are you still interested in fixing this bug?
Is there anything we can help with?

Honza

See also bug 1640371, should we fix both by one patch?

Honza

ok, I will check it out

Another nice test case that shows the problem if HTTP request for fav-icon. It's done by the browser (not by the page) and the stack trace points to resource:// modules.

Honza

This good-first-bug hasn't had any activity for 6 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.