This aligns all retargeting in a single place, so that we
can pass around "retarget strategy" to make sure we retarget
as expected in every single action.
After protocol fixes in all browsers, we can now scroll and click display:contents elements.
The only problem is that `elementsFromPoint()` misbehaves in Chromium and Firefox, so we
need a workaround. Hopefully, it will be fixed upstream - shadow dom spec folks think
"it becomes a real compatibility concern".
This needs Chromium 105 roll.
When target element is inside a non-main frame, there could be an
overlay in some of the parent frames that intercepts pointer events.
However, we never detected this case.
This restores the old hit target check, in addition to the new
hit target interceptor.
This way, we got some coverage for iframes and other quirky cases,
but keep the bullet-proof hit target check in place.
Fixes focus and blur management when `page.locator(…).focus()` and `page.locator(…).type(…)` are used which was regressed by 7a5b070 (#13510).
#13510 relied on an implicit assumption that this (conditional) [`blur`](7a5b070e95/packages/playwright-core/src/server/injected/injectedScript.ts (L672)) call would always be followed by a call that resulted in a newly focused element via this [`focus`](7a5b070e95/packages/playwright-core/src/server/injected/injectedScript.ts (L674)) call.
However, some elements are [not focusable](https://html.spec.whatwg.org/multipage/interaction.html#focusable-area), so we were blurring incorrectly, and losing focus that we should have maintained.
Two regression tests were added that pass on the commit prior to 7a5b070e9507b622877a2af010373585f2184196 (and match manual testing/expectations):
* `page.locator(…).focus()`: _keeps focus on element when attempting to focus a non-focusable element_
* `page.locator(…).type(…)`: _should type repeatedly in input in shadow dom_
Additionally, a third test (_should type repeatedly in input in shadow dom_) was added to check the invariant from #13510 that states:
> This affects [contenteditable] elements, but not input elements.
and allows us to introduce the targeted fix (contenteditble check before blur) without breaking FF again.
And _should type repeatedly in contenteditable in shadow dom with nested elements_ was added to ensure the above fix works with nest contenteditble detection.
Fixes#14254.
This fixes a few issues:
- strict mode was producing false negatives if multiple query paths
lead to the same element being picked;
- in some cases the number of intermediate items in the list was
exponential and crashed quickly.
What changed:
- `visible` engine is a real engine now;
- `capture` selectors are transformed to `has=` selectors for
easier implementation;
- chained querying switched from a list to a set to avoid
exponential size.
Firefox has a bug: calling `node.focus()` does make the node focused,
but some internal "current contenteditable node" is not changed.
Blurring the previous one and focusing the new one helps.
This introduces `role=button[name="Click me"][pressed]` attribute-style
role selector. It is only available under `env.PLAYWRIGHT_EXPERIMENTAL_FEATURES`.
Supported attributes:
- `role` is required, for example `role=button`;
- `name` is accessible name, supports matching operators and regular expressions:
`role=button[name=/Click(me)?/]`;
- `checked` boolean/mixed, for example `role=checkbox[checked=false]`;
- `selected` boolean, for example `role=option[selected]`;
- `expanded` boolean, for example `role=button[expanded=true]`;
- `disabled` boolean, for example `role=button[disabled]`;
- `level` number, for example `role=heading[level=3]`;
- `pressed` boolean/mixed, for example `role=button[pressed="mixed"]`;
- `includeHidden` - by default, only non-hidden elements are considered.
Passing `role=button[includeHidden]` matches hidden elements as well.
This introduces `locator('div', { has: locator })` syntax that matches elements containing other elements.
Can be used together with `hasText`.
Internally, has selector engine takes an inner selector escaped with double-quotes:
`div >> has="li >> span >> text=Foo" >> span`.
This changes previous layout shift attempt (see #9546)
to account for more valid usecases:
- On the first event that is intercepted we enforce the hit target. This
is similar to the current mode that checks hit target before the action,
but is better timed.
- On subsequent events we assume that everything is fine. This covers more
scenarios like react rerender, glass pane on mousedown, detach on mouseup.
This check is enabled by default, with `process.env.PLAYWRIGHT_NO_LAYOUT_SHIFT_CHECK`
to opt out.
