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.
- This leaves just `recordVideos` and `videoSize` options on the context.
- Videos are saved to `artifactsPath`. We also save their ids to trace.
- `context.close()` waits for the processed videos.
api(trace): introduce artifacts options
This introduces launch({ artifactsPath }) and newContext({ relativeArtifactsPath, recordTrace }) options.
- artifactsPath option controls the directory where all artifacts go. If not passed, artifacts are not collected.
- relativeArtifactsPath can be used to put context-specific artifacts into a subfolder. If not passed, shared artifactsPath is used.
- recordTrace controls trace recording.
We also expose trace types under playwright/types/trace.d.ts.
In the follow up:
- videos will be put into artifactsPath;
- downloads will be put into artifactsPath, or keep using existing downloadsPath when artifactsPath is not specified.
- Fill and click actions pass metadata to Progress.
- Progress reports success/failure through instrumentation.
- Tracer consumes ActionResult and ActionMetadata and records them.
Currently, only click and fill actions pass metadata to
contain the size of the change. Everything else should follow.
This introduces basic tracing enabled in our tests.
What is captured:
- network resources;
- snapshots at the start of most actions;
- snapshot after the test failure.
How this integrates with test runner:
- context fixture calls private method context._initSnapshotter() and uses Tracer to trace all events;
- all tests share a single test-results/trace-storage directory to store blobs;
- each test has its own trace file.
- npm run show-trace opens a bare-minimum trace viewer that renders snapshots.
