Netmonitor JS stack traces shouldn't include chrome frames
Categories
(DevTools :: Netmonitor, defect, P2)
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
Reporter | ||
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
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.
Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
Comment hidden (obsolete) |
Updated•6 years ago
|
Comment 4•5 years ago
|
||
This seems to be fixed, probably by bug 1392411. Re-open if chrome stacks still appear.
Comment 5•5 years ago
•
|
||
Sorry, not fixed yet!
STR:
- Open the Network panel on this page
- Reload the page
- Click the request for the document
- 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
Updated•5 years ago
|
Comment 7•4 years ago
|
||
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
Comment 9•4 years ago
|
||
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
Comment 10•4 years ago
|
||
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:
-
The Stack Trace panel is rendered here:
https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/client/netmonitor/src/components/StackTracePanel.js#67 -
It's using
StackTrace
component that is implemented here
https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/devtools/client/shared/components/StackTrace.js#37 -
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 -
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
Comment 12•4 years ago
|
||
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
Comment 14•4 years ago
|
||
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
Comment 16•4 years ago
|
||
Is someone working on this bug? I want to try it
Assigned to you, thanks for the help!
Honza
Comment 18•4 years ago
|
||
(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
Comment 20•4 years ago
|
||
See also bug 1640371, should we fix both by one patch?
Honza
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
Comment 25•4 years ago
|
||
This good-first-bug hasn't had any activity for 6 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Description
•