The method accepts a `ratio` option to assert the ratio
of the element in viewport. `ratio` defaults to `Number.MIN_VALUE`.
NOTE: this reverts commit d950f5b6ee and
adds `ratio` option support + does the rename.
Fixes#8740
This patch has 2 fixes:
- screenshot code was accidentally using main page context to fetch
page layout metrics instead of a utility context
- Avoid usage of `self.eval` inside utility context since it escapes
Firefox sandbox. This turns out to be an upstream bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1814898Fixes#20434
This is a new web-first assertion that should be used like this:
```ts
test('should work', async ({ page }) => {
const locator = page.locator('body');
// New web-first assertion.
await expect(locator).toIntersectViewport();
// The same functionality.
await expect.poll(() => locator.viewportRatio()).toBeGreaterThan(0);
});
```
Fixes#8740
- Rename internal selectors `has`, `control` and `attr` to
`internal:has`, `internal:control` and `internal:attr`.
- Fix `getByLabel()` to respect strictness, by introducing
`internal:label` selector.
- Move tests essential for ports to `selectors-by.spec`.
Instead of requiring all frames in the subtree to receive a particular
event, we rely on the browser's definition of load and DOMContentLoaded.
This changes logic in a few edge cases:
- Some browsers do not emit load event upon window.stop() at all.
- DOMContentLoaded does not wait for subframes, so they might not be
ready when passing `{ waitUntil: 'domcontentloaded' }`.
`networkidle` preserves the old logic.
We lack `documentId` when doing a reload over browser protocols, so
`reload()` waits for the next navigation to finish. Sometimes, the page
might issue a same-document navigation while reload is in progress,
which confuses the reload command.
To fix the issue, just ignore same-document navigations for reload,
because it is always a new document.
Previously, when some iframe started/finished a new navigation, we
could have removed and then re-addded load/domcontentloaded on the
main frame.
Drive-by: unflake wheel test in Firefox.
It could be that iframe was blocking some event, like load or networkidle,
and we never updated the lifecycle after the iframe was detached. This
lead to goto and other navigation commands to never resolve.
Currently, `loadstate` and `load` are two separate events in the protocol,
and are fired in this order. As a result, `waitForLoadState()` sometimes
resolves before the `'load'` event is fired, which is unexpected.
Also fixes a flaky test that assumed `load` event comes after `domcontentloaded`
for the empty page, which is not always a case in Chromium.
