testcafe
testcafe copied to clipboard
.click add :focus-visible pseudo class
What is your Scenario?
An elemenat is styled with :focus-visible {} pseudo class. Wen someone tabs to that element it gets appropriate styles based on :focus-visible {}. However, those styles have not to be applied when a click happens on the element.
This works manually well, but in testcafe the .click() method also gives the element :focus-visible.
What is the Current behavior?
.click() method gives :focus-visible on an element
What is the Expected behavior?
.click() method should not add :focus-visible.
What is your public website URL? (or attach your complete example)
<!DOCTYPE html>
<html lang="en">
<head>
<title>Home</title>
<meta charset="UTF-8"/>
<meta name="viewport" content="width=device-width"/>
<style>
main {
padding: 1rem;
}
h1 {
font-weight: bold;
font-size: 1.5rem;
}
h1:focus-visible {
outline: 0.2rem solid blue;
background-color: rgb(245, 245, 220);
}
</style>
</head>
<body>
<main>
<h1 id="headline" tabindex="0">Home page</h1>
</main>
</body>
</html>
What is your TestCafe test code?
fixture`Focus background`
.page(`./index.html`);
test.only('Should have no background-color after click', async () => {
const headline = Selector('#headline');
await t.click(headline);
const backgroundColor = await headline.getStyleProperty('background-color');
await t.expect(backgroundColor).notEql('rgb(245, 245, 220)');
});
Your complete configuration file
No response
Your complete test report
No response
Screenshots
No response
Steps to Reproduce
- serve the html
- run the test
TestCafe version
1.18.4
Node.js version
No response
Command-line arguments
testcafe chrome focus.e2e-spec.ts
Browser name(s) and version(s)
No response
Platform(s) and version(s)
No response
Other
No response
Thank you for the detailed bug description. I reproduced this behavior on my side.
Hi @vizdatom,
This issue is not reproduced if I use the experimental-proxyless option. Please try running the tests using this option and let us know your results.
Hi @miherlosev
I'm from the same team as @vizdatom. The original problem, when we reported it, was experienced on Safari (both desktop and mobile) - sorry we originally didn't include this information. Currently, we started to see the same problem with Chrome on Windows 10 too.
We tried experimental-proxyless option, as instructed, but it did not help. The issue is still the same. Tested with Testcafe 2.3.1.
We tried experimental-proxyless option, as instructed, but it did not help. The issue is still the same. Tested with Testcafe 2.3.1.
It's very strange. I ran the shared example in proxyless mode, and it works fine.

Could you please recheck it?
Hi @miherlosev
I tried to run the example again on chrome with --experimental-proxyless option and it does not pass for me but I think that it does not matter in general because this option would be a fix just for chrome even if it worked as intended. The problem appeared now on another browsers as well as I wrote above (for examle: Safari, Firefox, Edge etc.).

I checked the described behavior in the experimental-proxyless mode and it works as expected for me. However, it's true that the problem still exists in the other browsers.
Hi @vizdatom,
This issue is not reproduced with combination of [email protected] and the Google Chrome browser. Feel free to reopen this issue if you encounter it in other browsers.