Currently we only look at the top frame when computing the frameId

Maybe this windowId is helpful: https://searchfox.org/mozilla-central/rev/0688ffdef223dac527c2fcdb25560118c4e4df51/dom/chrome-webidl/ChannelWrapper.webidl#329

Not sure yet how important that actually is, but given that network events are used a lot I would rather see it fixed. It would also help me with bug 1637640 to actually have the correct frame ids reported. As such I'm taking that one.

I had a quick look into that and it seems to actually quite simple. The loadContext for HTTP requests and responses in content processes is actually a CanonicalBrowsingContext, and as such has an id property. That can perfectly be used here to filter out requests and responses not related to the page or sub frame itself, eg. favicons as requested by the browser.

After further investigation I noticed that for all network requests related to resources (style sheets, images, etc) the loadContext is of type nsILoadContext and not CanonicalBrowsingContext. As such no browsing context id is available, which could be used as frameId.

Honza, is there an easy way to get the browsing context of the document request for a resource request?

As it looks like we can use wrappedChannel.windowId to setup a mapping to the frameId. Each document request has the windowId and frameId set, and for resource requests the windowId is equal to the document requests. It works fine for me for top-level and sub browsing contexts.

I'll leave needinfo for Honza in case there is something more elegant.

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #4)

As it looks like we can use wrappedChannel.windowId to setup a mapping to the frameId. Each document request has the windowId and frameId set, and for resource requests the windowId is equal to the document requests. It works fine for me for top-level and sub browsing contexts.

I'll leave needinfo for Honza in case there is something more elegant.

Sorry for late answer, I'm not that much an expert to window ids, to be honest. On the child channel for http we collect toplevel content and outer window ids here: https://searchfox.org/mozilla-central/rev/ea7f70dac1c5fd18400f6d2a92679777d4b21492/netwerk/protocol/http/HttpChannelChild.cpp#2645-2661. Not sure if that is of any help.

But I believe that what you have found is what you need.

Thanks for your reply Honza. As it looks like I will indeed leave what I have right now. The code you pointed at is using the innerWindowId, which changes for each and every navigation request. But in our case we make use of the unique browsing context id.

On Ubuntu 18.04 tests are failing more often for debug builds
due to not received events. Bumping up the value here seems to
help.

Depends on D76835

Comment on attachment 9151976 [details]
Bug 1637363 - [remote] Bump default timeout for history.record() to 2s due to timeouts of debug builds.

Revision D76992 was moved to bug 1638196. Setting attachment 9151976 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/bf7719c227fb