This is a speculative fix for the following scenario:
- Main frame A creates a child frame B.
- B navigates cross-origin and forces an oopif.
- Target.attachedToTarget for B arrives.
- B loads and creates execution contexts.
- Process with A creates an execution context in the
(still local) frame B (e.g. with document.write?)
- Process with A sends executionContextCreated and
overwrites the execution context that came from B.
- Process with A finally sends frameDetached for B,
and we ignore it since we already have the B target.
This sequence results in a stale execution context
from process A that is actually not present in B.
Overall, events coming from process A for the frame
that has already moved to an oopif B should be ignored.
Seems totally safe! This is also pure specultation
from analyzing protocol logs, no easy repro found.
This is an attempt to improve video performance when encoding
does not keep up with frames. This situation can be reproduced
by running multiple encoders at the same time.
Added `utils/video_stress.js` to manually reproduce this issue.
Observing ffmpeg logs, it does not do any encoding initially and
instead does "input analysis / probing" that detects fps and other
parameters. By the time it starts encoding (launches vpx and creates
the video file), we already have many frames in the buffer.
Reducing probing helps:
`-avioflags direct -fpsprobesize 0 -probesize 32 -analyzeduration 0`
Another issue observed is questionable default `-threads` value.
We compile without threads support, so logs say "using emulated threads".
For some reason, setting explicit `-threads 1` (or any other value)
makes it better when cpu is loaded.
Without this, Playwright's CDP feature leaves unreachable
targets (namely OOPIFs).
This change allows for more advanced experimentation in user-land
without relying on out-of-band CDP connections and clients.
Now you can, for example, call `DOM.getDocument` on the
page OR main frame, observe there is an iframe node with
no `contentDocument` (i.e. OOPIF), make note of the referenced
`frameId`, and then iterate of page.frames() calling `Target.getInfo`
on each to link the Playwright Frame with the CDP `frameId` and
then recurse.
Relates #8113
