We might not ever get the "download finished" event when closing the context:
- in Chromium, for any ongoing download;
- in all browsers, for failed downloads.
This should not prevent closing the context. Instead of waiting for the
download and then deleting it, we force delete it immediately and reject
any promises waiting for the download completion.
- Introduce internal "out of process" start()/stop() mode.
- This mode is used both in regular tests and installation tests.
- Emulate basic driver installation, browser download and running.
- Snap to buttons, inputs, selects, etc.
- Try `<label>` selector in addition to the element.
- Use parent selectors when needed.
- Remove xpath fallback as it should be covered with css.
Consider the following situation (one among many possible).
- FrameA has an oopif child FrameB;
- FrameA navigates to same-process origin (e.g. about:blank);
- at the same time, FrameC is attached to the FrameB in the
FrameB's process.
In this case, we get `frameNavigated` event for FrameA, immediately
followed by `frameAttached` event for FrameC. Since we detach all
FrameA's child frames on navigation, including the oopif FrameB,
there is no parent frame for FrameC to attach to.
In general, multiple processes coming from oopif may send their
events in wildly different order, and their view about the frame
tree may not always correspond to the "up to date" frame tree as
seen from the main frame's process. We try to keep our frame tree
aligned with what main process thinks, and ignore events that
reference frames absent in this tree.
Drive-by: handle filechooser exceptions because of async processing.
This changes `text=` and `:text()` selectors to match the element when:
- it's combined text content matches the text;
- combined text content of any immediate child does not match the text.
This allows the following markup to match "Some bold and italics text":
`<div>Some <b>bold</b> and <i>italics</i> text</div>`.
For the reference, "combined text content" is almost equal to `element.textContent`,
but with some changes like using value of `<input type=button>` or ignoring `<head>`.
This also includes some caching optimizations, meaningful in complex matches
that involve multiple calls to the text engine.
Performance changes (measured on large page with ~25000 elements):
- `:has-text()` - 14% faster.
- `text=` - 50% faster.
- `:text()` - 0-35% slower.
- `:text-matches()` - 28% slower.
This makes dialogs disappear and prevents stalling.
Pros:
- No need to worry about dialogs for most users.
- Those that wait for a specific dialog still get to control it.
Cons:
- Those who use Playwright to show interactive browser will have
to add an empty 'dialog' handler to prevent auto-dismiss.
We do this in cli.
This patch starts downloading FFMPEG like we download our browsers
instead of bundling it in the NPM package.
With this patch, NPM size is reduced from 8.8MB to 1.7MB.
Consequences:
- `npx playwright` is drastically faster now
- playwright driver for language bindings is way smaller
- projects that bundle Playwright can pass Apple Notorization
Fixes#5193
- Intercept CSSOM modifications and recalculate overridden css text.
- When css text does not change, use "backwards reference" similar
to node references.
- Set 'Cache-Control: no-cache' for resources that could be overridden.
This change is adding a new property on the BrowserContextOptions class called `_debugName`. This property allows defining a user-friendly name for the browser context, and currently it is being used in one place, the Trace Viewer. When user provides the new value in the following way:
```typescript
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch();
const context = await browser.newContext({ _traceDir: __dirname, _debugName: 'My custom testcase name' });
await context.close();
await browser.close();
})();
```
The `_debugName` will be saved in the `*.trace` file for this browser context, on the `context-created` event, under the key `debugName`.
Later, when such a trace is displayed using Trace Viewer, the `debugName` will be displayed in the dropdown in the top right part of the app instead of the actual trace filename.
Fixes#5157.
This introduces an http server that serves our frontend and our snapshots. There is more work to untangle the big server into a few modules.
This change allows us:
- Maybe eventually serve the trace viewer as a web page.
- Rely on browser caches for fast snapshot rendering. This PR also adds "snapshot on hover" feature, subject to change.
feat(trace viewer): Extending existing NetworkTab view
Currently the network tab contains a limited amount of information on the resources that were loaded in the browser. This change proposes extending the details displayed for each resource, to include:
- HTTP method,
- Full url,
- Easily visible response content type,
- Request headers,
- Request & response bodies.
Such level of information could help quickly understand what happened in the application, when it was communicating with backend services. This can help debug tests quicker to figure out why they are failing.
This implementation still needs some clean up & tests improvement, but I wanted to propose such changes and gather your feedback before going too far.
- Instead of capturing snapshots on demand, we now stream them
from each frame every 100ms.
- Certain actions can also force snapshots at particular moment using
"checkpoints".
- Trace viewer is able to show the page snapshot at a particular
timestamp, or using a "checkpoint" snapshot.
- Small optimization to not process stylesheets if CSSOM was not used.
There still is a lot of room for improvement.
