STRs:

• open a page with an iframe, eg http://janodvarko.cz/tests/fission/case1/index.html
• subscribe to network events for all contexts
• reload or navigate the iframe (either using browsingContext commands, or manually by right clicking on the iframe...)

ER: The network events for the iframe navigation should be associated with the context id of the iframe
AR: The network events are using the parent window context id

Subsequent requests (eg favicon) done in the iframe will have the correct context id, the one from the iframe.

This means we get the wrong navigation id in those requests.

We also have the same issue when dynamically adding an iframe in a page, the initial request to create the iframe will be mapped to the parent's context id, which makes one puppeteer test fail (network Request.frame should work for subframe navigation request).

Hi Valentin,

See description above for more details, tldr channels created for an iframe navigation always seem "owned" by the iframe's parent context.

At the moment we are retrieving the BrowsingContext corresponding to a channel via channel.loadInfo.browsingContextID, and we are doing this when receiving the activity ACTIVITY_SUBTYPE_REQUEST_HEADER. I've also tried to look at the loadContext's associatedWindow or topFrameElement, but they are always set to the frame's parent.

Do you know if there is a way to link those channels to the BrowsingContext of the iframe being loaded/navigated?

Ah I see there is frameBrowsingContextID on the loadInfo, which seems to do exactly what I asked. Leaving the ni? in case you have some more insights, but looks like we have enough to fix it on our own.

I don't have any more info. I'm glad frameBrowsingContext gets you the information you need.

Depends on D196326

https://hg.mozilla.org/mozilla-central/rev/478e4fb80c4d
https://hg.mozilla.org/mozilla-central/rev/1b43e68405d0