source: 'pageOrInProcessIframe' | 'oopif' | 'worker' (useful if/when we start listening to other target types for their network requests)
It would also be useful to split up main frame requests and requests from in-process iframes, because sometimes we only want to deal with one or the other. One idea was more or less crdp.TargetType | 'oopif' for the enum.
Other open question: how to populate this in the network records? We've always been able to construct the network records purely from the devtoolslog, but there's not necessarily enough information in there to recreate this source enum (especially in timespans when the initial load wasn't seen). Each request has a frameId, but we don't always have frames to match those up to.
DevtoolsLog + Trace may work, because TracingStartedInBrowser and navigation events would allow reconstructing the frame tree (and changes to it). Workers may not work for this, though.
augmented devtoolslog with Page and Target events? Unclear if there's enough there. (EDIT: we like this)
connorjclark
commented
1 year ago
Splitting off of #14078 from some discussions that happened last week.
Rather than rely on the
sessionIdapproach we've used to determine if requests are coming from an OOPIF (and have had to add some hacks to preserve as DevTools and puppeteer were added as protocol intermediaries), we should add an explicit network request property that marks where the request came from.Possibilities discussed (modulo naming):
fromMainProcess: booleansource: 'pageOrInProcessIframe' | 'oopif' | 'worker'(useful if/when we start listening to other target types for their network requests)It would also be useful to split up main frame requests and requests from in-process iframes, because sometimes we only want to deal with one or the other. One idea was more or less
crdp.TargetType | 'oopif'for the enum.Other open question: how to populate this in the network records? We've always been able to construct the network records purely from the devtoolslog, but there's not necessarily enough information in there to recreate this source enum (especially in timespans when the initial load wasn't seen). Each request has a frameId, but we don't always have frames to match those up to.
DevtoolsLog+Tracemay work, becauseTracingStartedInBrowserand navigation events would allow reconstructing the frame tree (and changes to it). Workers may not work for this, though.PageandTargetevents? Unclear if there's enough there. (EDIT: we like this)