core(oopifs): skip OOPIF network records in some gatherers #7640
Conversation
| @@ -103,6 +103,18 @@ module.exports = class NetworkRequest { | |||
| this.fetchedViaServiceWorker = false; | |||
| /** @type {string|undefined} */ | |||
| this.frameId = ''; | |||
| /** | |||
| * @type {string|undefined} | |||
| * Only set for OOPIFs. This is the targetId of the protocol target from which this | |||
There was a problem hiding this comment.
technically according to the types this can be undefined even when there was a source, but I have never been able to see this happen with an OOPIF
I unconvinced myself we should surface them in the regular audit results. The things flagged in OOPIFs will tend to be on another level actionability-wise. While you might have some control over the third parties you include, you almost definitely have no control over the third parties that your third parties include. Without being able to pinpoint that this ad iframe X was added by script Y and so the script is the thing you need to fix, I feel like surfacing the OOPIF data will just be noise. You could probably make this argument with a lot of things in the report, but the things discovered in OOPIFs will just overwhelmingly be in this bucket compared to unknown CDN assets and whatnot. Add to this the complexity that we need to start talking to other targets to get this information and it just feels extra not worth it. I'm not totally against it for 5.0 if others feel differently, but IMO, it's not the best use of our efforts.
Correct.
Perhaps, depending on the ongoing, spirited (but perhaps short-lived if I am out numbered) debate :) |
…oogleChrome#7640)" This reverts commit bed02b4.
Summary
Some cleanup now that we're in an OOPIF world. Because they are different targets the commands will fail for these records and generated a lot of log noise. Nothing is changed functionality-wise from before we enabled OOPIFs (or even current master), and I think a discussion of whether we should surface these in the report is a separate topic. For now, we skip them.
Related Issues/PRs
#6922 #7608