Instead of multiple `system-out` entries we produce a single one
with concatenated content. This is compatible with various junit xml
parsers in the wild.
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 patch adds a general-purpose grid framework to parallelize
Playwright across multiple agents.
This patch adds two CLI commands to manage grid:
- `npx playwright experimental-grid-server` - to launch grid
- `npx playwrigth experimental-grid-agent` - to launch agent in a host
environment.
Grid server accepts an `--agent-factory` argument. A simple
`factory.js` might look like this:
```js
const child_process = require('child_process');
module.exports = {
name: 'My Simple Factory',
capacity: Infinity, // How many workers launch per agent
timeout: 10_000, // 10 seconds timeout to create agent
launch: ({agentId, gridURL, playwrightVersion}) => child_process.spawn(`npx`, [
'playwright'
'experimental-grid-agent',
'--grid-url', gridURL,
'--agent-id', agentId,
], {
cwd: __dirname,
shell: true,
stdio: 'inherit',
}),
};
```
With this `factory.js`, grid server could be launched like this:
```bash
npx playwright experimental-grid-server --factory=./factory.js
```
Once launched, it could be used with Playwright Test using env variable:
```bash
PW_GRID=http://localhost:3000 npx playwright test
```
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.
