fix(test runner): avoid internal error for step end without begin
Consider the following scenario:
- Test finishes and starts tearing down fixtures.
- Fixture teardown starts a step S and then times out.
- We declare the test finished (with timeout).
- Dispatcher shuts down the worker and spins a new one for a retry.
Additionally, it clears steps information for the test to be
ready for the new retry. Step S information is lost.
- Meanwhile, during worker teardown, the step S does
actually finish (usually with an error), and we send stepEnd for S.
- Dispatcher does not know what to do with step S end and
prints an internal error.
The fix is to ignore certain messages from the shutting down worker that failed.
When browser receives multiple header values for the same header name,
we present them as LF-separated value. This is not considered valid in
Node, so we should split by LF when serving a snapshot.
There more invalid characters in headers, so just in case we try/catch it.
- Simplify by only considering client/ vs non-client/
- Fix stack traces when calling from other playwright code, e.g. from the cli
- Account for re-entrant calls that happen when
instrumenting context creation/desctruction
- Add tests
- Fix StackTraceView on Windows
When sharing a context between tests and using `'on-first-retry'` we
could end up with tracing still running in non-retried tests. That's
extra overhead without a reason.
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
Using a worker fixture forces a new worker. This might be unexpected
when part of the test file runs in one worker, and another runs
in another worker. Top-level use of worker fixtures is still fine.
