.click add :focus-visible pseudo class

vizdatom commented 2 years ago

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

Dmitry-Ostashev commented 2 years ago

Thank you for the detailed bug description. I reproduced this behavior on my side.

miherlosev commented 1 year ago

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.

Nikolaj1010 commented 1 year ago

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.

miherlosev commented 1 year ago

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?

Nikolaj1010 commented 1 year ago

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.).

AlexKamaev commented 1 year ago

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.

miherlosev commented 1 year ago

Hi @vizdatom,

This issue is not reproduced with combination of testcafe@3.0.1 and the Google Chrome browser. Feel free to reopen this issue if you encounter it in other browsers.

DevExpress / testcafe