Open Bug 1280266 Opened 5 years ago Updated 8 months ago

Netmonitor JS stack traces shouldn't include chrome frames

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox50 affected)

Tracking Status
firefox50 --- affected

People

(Reporter: jsnajdr, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug)

Attachments

(1 file)

Requests JS stack traces in Netmonitor sometimes show chrome:// stack frames. This is confusing for users - they should only see the JS code from the page content.

The chrome:// frames should be shown only in browser toolbox.

Two examples of this behavior:

1) When the page is reloaded, the main document request shows stack trace from the browser calling into webNav.reload at chrome://browser/content/tab-content.js:73

2) When issuing a request from the console (i.e., type "fetch('x')"), the request stack trace contains frames like:

WCA_evalWithDebugger resource://devtools/server/actors/webconsole.js:1299
One way how to implement this: when calling "components.stack", it eventually calls GetFirstSubsumedFrame at [1], which filters the frames by the current JSContext's principal. When called from network-monitor.js (at [2]), it's the system principal. It would help if we could somehow pass the content principal there instead.

Nick, do you have any advice?

[1] https://dxr.mozilla.org/mozilla-central/source/js/src/vm/SavedStacks.cpp#556
[2] https://dxr.mozilla.org/mozilla-central/source/devtools/shared/webconsole/network-monitor.js#220
Blocks: 1134073
Flags: needinfo?(nfitzgerald)
https://github.com/fitzgen/gecko-dev/blob/master/js/src/doc/SavedFrame/SavedFrame.md has the documentation you're looking for.

Basically, Cu.waiveXrays(stack) will give you the content's view of the stack.
Flags: needinfo?(nfitzgerald)
Assignee: nobody → jsnajdr
Assignee: jsnajdr → nobody
Product: Firefox → DevTools

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

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

@Brian, could you please look at this.

Thanks,
Honza

Has STR: --- → yes
Flags: needinfo?(bhackett1024)
Priority: P3 → P2
Flags: needinfo?(bhackett1024)

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?

Flags: needinfo?(odvarko)

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

Honza

Flags: needinfo?(odvarko) → needinfo?(sebastianzartner)

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

Flags: needinfo?(sebastianzartner)

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

Flags: needinfo?(nchevobbe)

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

Flags: needinfo?(nchevobbe)

Thanks Nicolas!
Honza

Keywords: good-first-bug

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

Flags: needinfo?(nchevobbe)

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

Assigned to you, thanks for the help!

Honza

Assignee: nobody → mariatua2
Status: REOPENED → ASSIGNED

(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

Flags: needinfo?(nchevobbe)

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

Honza

Flags: needinfo?(mariatua2)

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

Honza

See Also: → 1640371

ok, I will check it out

Flags: needinfo?(mariatua2)

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.

Assignee: mariatua2 → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.