Sometimes we get "Network.webSocketWillSendHandshakeRequest" in Chromium.
Perhaps websocket is restarted because of chrome.webRequest extensions api?
Or maybe the handshake response was a redirect?
This reports websocket twice and triggers an assert.
feat(api): add explicit async testInfo.attach
We add an explicit async API for attaching file paths (and Buffers) to
tests that can be awaited to help users ensure they are attaching files
that actually exist at both the time of the invocation and later when
reporters (like the HTML Reporter) run and package up test artifacts.
This is intended to help surface attachment issues as soon as possible
so you aren't silently left with a missing attachment
minutes/days/months later when you go to debug a suddenly breaking test
expecting an attachment to be there.
NB: The current implemntation incurs an extra file copy compared to
manipulating the raw attachments array. If users encounter performance
issues because of this, we can consider an option parameter that uses
rename under the hood instead of copy. However, that would need to be
used with care if the file were to be accessed later in the test.
Consider the following scenario:
- Tracing is started.
- API call is made (e.g. page.waitForResponse), almost finishes, and
enters onAfterCall where it starts a snapshot.
- tracing.stopChunk is called, and waits for existing actions to finish.
However, it does so by calling onAfterCall one more time.
- tracing.stopChunk removes instrumentation listener and returns
to the client.
- Client starts zipping files.
- Original API call finishes the snapshot and saves it to the trace file.
This results in trace file being written to while the zip is still working.
1. Fixtures defined in test.extend() can now have `{ option: true }` configuration that makes them overridable in the config. Options support all other properties of fixtures - value/function, scope, auto.
```
const test = base.extend<MyOptions>({
foo: ['default', { option: true }],
});
```
2. test.declare() and project.define are removed.
3. project.use applies overrides to default option values and nothing else. Any test.extend() and test.use() calls take priority over config options.
Required user changes: if someone used to define fixture options with test.extend(), overriding them in config will stop working. The solution is to add `{ option: true }`.
```
// Old code
export const test = base.extend<{ myOption: number, myFixture: number }>({
myOption: 123,
myFixture: ({ myOption }, use) => use(2 * myOption),
});
// New code
export const test = base.extend<{ myOption: number, myFixture: number }>({
myOption: [123, { option: true }],
myFixture: ({ myOption }, use) => use(2 * myOption),
});
```
Makes it easier to understand that expect does indeed have a separate timeout.
```
Error: expect(received).toHaveCount(expected) // deep equality
Expected: 0
Received: 1
Call log:
- expect.toHaveCount with timeout 500ms
- waiting for selector "span"
- selector resolved to 1 element
- unexpected value "1"
- selector resolved to 1 element
- unexpected value "1"
- selector resolved to 1 element
- unexpected value "1"
```
Turns out we were using wrong formula; with the config we had in place,
proper-lock-file would give up to aquire lock after 49 seconds of
waiting.
With the proper configuration, we'll keep re-trying for 10 minutes.
Fixes#10354
This patch:
- consolidates all distribution-specific information in a single
location
- updates list of required dependencies for WebKit on Arb64 Ubuntu 20.04
This fixes a common scenario where you setup a route,
and the page closes (e.g. test ends) while we are aborting/continuing
some requests that are not instrumental to the test itself.
This replaces previous `checkHitTarget` heuristic that took place before the action
with a new `setupHitTargetInterceptor` that works during the action:
- Before the action we set up capturing listeners on the window.
- During the action we ensure that event target is the element we expect to interact with.
- After the action we clear the listeners.
This should catch the "layout shift" issues where things move
between action point calculation and the actual action.
Possible issues:
- **Risk:** `{ trial: true }` might dispatch move events like `mousemove` or `pointerout`,
because we do actually move the mouse but prevent all other events.
- **Timing**: The timing of "hit target check" has moved, so this may affect different web pages
in different ways, for example expose more races. In this case, we should retry the click as before.
- **No risk**: There is still a possibility of mis-targeting with iframes shifting around,
because we only intercept in the target frame. This behavior does not change.
There is an opt-out environment variable PLAYWRIGHT_NO_LAYOUT_SHIFT_CHECK that reverts to previous behavior.
