1838457 - Early Hints Preload channels do not provide information to devtools.

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Description

[Manuel Bucher [:manuel]]

Attachment: devtool-screenshot.png

They are greyed out and no HTTP-header/-body information appears.

How to reproduce (in Nightly v115):

1. Go to a site returning Early Hint preload, e.g. https://sourceforge.net/
2. open devtool networking tab and reload
3. scroll to top and click on some load initiated by Early Hints

Comment 1

[Manuel Bucher [:manuel]]

Hubert, do you know offhand what could be missing on the Early Hint preloaded channel for the information to not show up?

Comment 2

[Hubert Boma Manilla (:bomsy)]

Hi Manuel,
I think these requests are missing information for the response headers. https://searchfox.org/mozilla-central/rev/986024d59bff59819a3ed2f7c1d0f5254cdc3f3d/devtools/shared/network-observer/NetworkObserver.sys.mjs#504,583

I'm not too clear though.
Are these requests from preload channels? I tested on v114 and it seems like these where displayed as 200 requests? Did this regress?

Comment 3

[Manuel Bucher [:manuel]]

In v114 these preload channels aren't shown in devtools yet (Bug 1828882). The issue only surfaced with v116. And I somehow messed up the version number. It was on Nightly 116. In 114 Early Hints is disabled by default if Early Hints were enabled, the channels would just be missing in devtools. Thanks for the link in NetworkObserver.sys.mjs. It'll help with debugging why the info doesn't show up.

Comment 4

[Manuel Bucher [:manuel]]

It is not just the header info, but all the other infos as well (status, timings, transferred, size, timings, security). With this newer test page I sometimes see the channel info in devtools. So probably a timing issue. I don't know how to debug this.

Comment 5

[Manuel Bucher [:manuel]]

Hi Hubert, I took another look and at https://searchfox.org/mozilla-central/rev/986024d59bff59819a3ed2f7c1d0f5254cdc3f3d/devtools/shared/network-observer/NetworkObserver.sys.mjs#504,583 the header information is available (just dumping the extraStringData). So from necko perspective this info is made available.

Can you take another look what is going wrong here?

• https://lab.neon.rocks/0/eh/images-0.html <- sometimes the channel info is displayed
• https://lab.neon.rocks/1000/eh/images-0.html <- the channel info is displayed less often (here the main response takes 1s and the images load earlier)

Comment 6

[Valentin Gosu [:valentin] (he/him)]

I think we need to add some context here about how EH works:
When we get a 103 response with a link header, we create channels that preload those resources. The channels get suspended in OnStart request. When a different resource in the page then tries to load that resource, we resume the channel, and connect the parent to the already created nsHttpChannel. https://firefox-source-docs.mozilla.org/networking/early_hints.html#early-hints-response-on-main-document-load
Not sure if this is causing the netmonitor to be confused, as technically both the early hint and later load actually use the same nsHttpChannel.

Comment 7

[Manuel Bucher [:manuel]]

Debugging with bomsy lead that the network-event-listener being destroyed at network-events.js#212

The comment below the line is relevant, because there is an exception for the navigational request:

network-events.js#214-225:

// Avoid destroying the navigation request, which is flagged with previous document's innerWindowId.
// When navigating, the WindowGlobal we navigate *from* will be destroyed and notified here.
// We should explicitly avoid destroying it here.
// But, we still want to eventually destroy them.
// So do this when navigating a second time, we will navigate from a distinct WindowGlobal
// and check that this is the top level window global and not an iframe one.
// So that we avoid clearing the top navigation when an iframe navigates
//
// Avoid destroying the request if innerWindowId isn't set. This happens when we reload many times in a row.
// The previous navigation request will be cancelled and because of that its innerWindowId will be null.
// But the frontend will receive it after the navigation begins (after will-navigate) and will display it
// and try to fetch extra data about it. So, avoid destroying its NetworkEventActor.

We probably need to add exceptions for the early hint requests, because they get created at a similar time to the navigational request?

Comment 8

[Hubert Boma Manilla (:bomsy)]

(In reply to Manuel Bucher [:manuel] from comment #7)

Debugging with bomsy lead that the network-event-listener being destroyed at network-events.js#212

The comment below the line is relevant, because there is an exception for the navigational request:

network-events.js#214-225:

// Avoid destroying the navigation request, which is flagged with previous document's innerWindowId.
// When navigating, the WindowGlobal we navigate *from* will be destroyed and notified here.
// We should explicitly avoid destroying it here.
// But, we still want to eventually destroy them.
// So do this when navigating a second time, we will navigate from a distinct WindowGlobal
// and check that this is the top level window global and not an iframe one.
// So that we avoid clearing the top navigation when an iframe navigates
//
// Avoid destroying the request if innerWindowId isn't set. This happens when we reload many times in a row.
// The previous navigation request will be cancelled and because of that its innerWindowId will be null.
// But the frontend will receive it after the navigation begins (after will-navigate) and will display it
// and try to fetch extra data about it. So, avoid destroying its NetworkEventActor.

We probably need to add exceptions for the early hint requests, because they get created at a similar time to the navigational request?
Hi Manuel, That totally makes sense. Is there any thing else you need for this?

Comment 9

[Manuel Bucher [:manuel]]

I'm not sure yet how to fix. It seems like we need to set the correct innerWindowId either by delaying setting the BrowserContext in the LoadInfo to when the BrowserContext has the updated innerWindowId or have some other mechanism to have the NavigationalRequest already have the updated innerWindowId so that the Early Hints Requests, that get created from the NavigationalRequest also already have the newer aInnerWindowId.

Will continue to investigate tomorrow.