2013043 - Reporting API reports are not shown in the devtools network tab

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect, P2)

Description

[Nicolas Chevobbe [:nchevobbe]]

STR:

1. Go to about:config
2. Set dom.reporting.enabled and dom.reporting.header.enabled to true
3. Navigate to https://nchevobbe--019c088c009977e6946581840457796c.web.val.run/
4. Open DevTools, select the Netmonitor
5. Click the trigger report button

(Note that the STR seem finicky, the report might only be sent once, when opening the URL in a new tab. After reloading (even hard), it doesn't show up reliably)

Similarly to Bug 1886790, the report POST request is not showing in the regular toolbox netmonitor, only in the Browser Toolbox netmonitor.

This is where we return false https://searchfox.org/firefox-main/rev/a771bf78b90de89e0ea9d17caaa64ffa240ecd7e/devtools/shared/network-observer/NetworkUtils.sys.mjs#541,608-609

function matchRequest(channel, filters) {
...
    const win = lazy.NetworkHelper.getWindowForRequest(channel);
    return windows.includes(win);

because in https://searchfox.org/firefox-main/rev/a771bf78b90de89e0ea9d17caaa64ffa240ecd7e/devtools/shared/network-observer/NetworkHelper.sys.mjs#254-264

getWindowForRequest(request) {
  try {
    return this.getRequestLoadContext(request).associatedWindow;
  } catch (ex) {
    // On some request notificationCallbacks and loadGroup are both null,
    // so that we can't retrieve any nsILoadContext interface.
    // Fallback on nsILoadInfo to try to retrieve the request's window.
    // (this is covered by test_network_get.html and its CSS request)
    return request.loadInfo.loadingDocument?.defaultView;
  }
},

this.getRequestLoadContext(request).associatedWindow throws with Uncaught NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsILoadContext.associatedWindow]
so we enter the catch block, and request.loadInfo.loadingDocument is null, so we end up returning undefined

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Valentin, would you know where those channels are created and if we can properly set their loading document?

Comment 2

[Valentin Gosu [:valentin]]

They are sent from mozilla::dom::SendReports
I'm also not sure if these reports should have a loadingDocument, since we're not actually loading the response of the reporting API report.
Simon is working on the Reporting API so he can provide more info.

Comment 3

[Simon Farre [:sfarre]]

Is this really an issue still? I see the request being made in devtools (under the network panel)? Or is this related to something different?

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Simon Farre [:sfarre] from comment #3)

Is this really an issue still? I see the request being made in devtools (under the network panel)? Or is this related to something different?

it's only showing up in the Browser Toolbox Netmonitor (https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/index.html), which is a "special" DevTools toolbox, mostly aimed at Firefox engineers. We want to have it displayed in the Tab toolbox netmonitor, which is what Web Developers are using. The tab netmonitor needs to have a way to match a given channel with the current opened tab (done in NetworkUtils.sys.mjs), which it usually does either by checking the associatedWindow or the loadingDocument (as said in Comment 0).
If it's not possible to set those on the channel, we might look for another flag (e.g. browsingContextId, innerWindowId, …) so we could match it with the tab's page.

Does that make sense Simon?

Comment 5

[Julian Descottes [:jdescottes]]

Feature seems scheduled for 149, we should have devtools support at the same time.

Comment 6

[Simon Farre [:sfarre]]

Attachment: Bug 2013043 - Set associated browsing context ID for fetch r=#necko-reviewers,#dom-worker-reviewers,#devtools-reviewers

Work in progress.

Comment 7

[Simon Farre [:sfarre]]

I've added a WIP here, but it's touching rather more than I want. It definitely would need review from a few people I believe, if I were to move this out of planned changes.

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

Attachment: WIP: Bug 2013043 - Rename workerAssociatedBrowsingContextID into associatedBrowsingContextID

Depends on D283896

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 2013043 - [devtools] Show Reporting API requests in Netmonitor. r=#devtools

This is done by checking the channel associatedBrowsingContext in NetworkUtils matchRequest function.
A test is added to make sure Reporting API requests are visible in the Netmonitor
and that we can inspect their payload.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2b68fb9e0e27
https://hg.mozilla.org/integration/autoland/rev/167e2110755d
Set associated browsing context ID for fetch r=necko-reviewers,dom-worker-reviewers,devtools-reviewers,cookie-reviewers,manuel,nchevobbe,edgul,kershaw,edenchuang
https://github.com/mozilla-firefox/firefox/commit/4de5de5f2fbb
https://hg.mozilla.org/integration/autoland/rev/8a2a412f3291
[devtools] Show Reporting API requests in Netmonitor. r=devtools-reviewers,bomsy

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/167e2110755d
https://hg.mozilla.org/mozilla-central/rev/8a2a412f3291