`perf-diagnostics-third-party` is broken with FR runner

Some OOPIF requests are emitting a Network.responseReceived event but no Network.requestWillBeSent event.

Bisect range on yarn smoke perf-diagnostics-third-party --fraggle-rock: https://chromium.googlesource.com/chromium/src/+log/e2e042f4c34cff4555412fc4bba955cf963e4e39..26600153b33329939cc181a06f5978552283d9ad

This CL is probably where the issues started: https://chromium.googlesource.com/chromium/src/+/b03884a3a1ffb3ad8ec269590843203db9e7a386

Disabling some of the features from that CL did fix the issue with perf-diagnostics-third-party https://github.com/GoogleChrome/lighthouse/pull/14081

Min repro: https://gist.github.com/adamraine/e9ae2e811bde239db24a47535008e228

I used the min repro to bisect again, and it returned the same commit range as doing yarn smoke perf-diagnostics-third-party --fraggle-rock, so it could be helpful when debugging.

[adamraine]

I debugged this with @caseq today.

Puppeteer does it’s own Target.setAutoAttach that happens before we do it and they set waitForDebugger to false: https://github.com/puppeteer/puppeteer/blob/353358a996dcaa1cda75ec79e4111252c91f243d/src/common/FrameManager.ts#L143-L146

When we set our own Target.setAutoAttach after this, it doesn’t override the value originally set by Puppeteer, so we are not actually waiting for the debugger when using Lighthouse driven by Puppeteer (i.e. fraggle rock).

Perhaps the issue with oopif-scripts is similar where the DT frontend calls Target.setAutoAttach before us, and our call gets negated. Or maybe it’s coming from pptr again because we do use pptr to drive the DT smokes. I haven’t verified this yet.

[adamraine]

https://github.com/puppeteer/puppeteer/issues/8507