This matches when each expected item from the array
is matched to one of the resolved elements, in order.
Note this performs both "sub-array" and "substring" matching.
Drive-by: documentation fixes.
Drive-by: added "selector resolved to 3 elements" log line
when expecting arrays.
When using `evaluate` or `evaluateHandle` internally during actions
like `click`, we can sometimes get protocol errors if page
navigates. In this case, we throw the protocol error right away.
Instead, we can treat such a protocol error similar to "detached"
error and retry in the new execution context.
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.
