Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Click misbehaviour for Chromium in visible area #1240

Closed
DavertMik opened this issue Mar 5, 2020 · 4 comments · Fixed by #1823
Closed

[BUG] Click misbehaviour for Chromium in visible area #1240

DavertMik opened this issue Mar 5, 2020 · 4 comments · Fixed by #1823
Labels
browser-chromium upstream This is a bug in something playwright depends on, like a browser.

Comments

@DavertMik
Copy link
Contributor

DavertMik commented Mar 5, 2020

Context:

  • Playwright Version: 0.11.1
  • Operating System: Mac
  • Using interfactive pause in CodeceptJS (hope not that much related)
  • React on the frontend. I assume this is related

Scenario:

  • open https://wetransfer.com first time
  • agree on terms
  • reload page
  • you will see splash screen with 3 buttons "Sign up for free", "Use Pro" and "No thanks"
  • click "Sign up for free button"

Expected behavior:

  • a splash panel from right with sign up for will appear

Current behavior

  • when clicked manually in chrome = same as expected
  • when clicked in firefox = same as expected
  • when click in webkit = same as expected
  • when clicked in headless chromium = same as expected
  • when clicked in chromium BUT the button is in visible area - button is not clicked but background element receives a click and a new tab with a post is opened

Videos attached:

  1. Executing this test in Firefox.- expected behavior: https://recordit.co/Q1z7lw916a
  2. Executing in Chromium - clicking on element triggers event for background (BUG), clicking manually works as expected https://recordit.co/qtix0XpMoc
  3. Executing in Chromium but when the button is not inside viewport - expected behavior https://recordit.co/cKGdq7HfNr

P.S. Bug appears to be Chrome-wide. Similar behavior happens in WebDriver & Puppeteer.
Everything works fine in headless mode but crashes once an element is visible.

@aslushnikov
Copy link
Collaborator

aslushnikov commented Mar 5, 2020

@DavertMik Somehow I don't get the "sign up for free" button at all;

image

When I click "Take me to free" - I get re-directed to a regular wetransfer interface :(
Any chance you can save .mhtml and attach it here?

@DavertMik
Copy link
Contributor Author

DavertMik commented Mar 7, 2020

@aslushnikov

UPDATE You are right, they changed the behavior a bit. Anyway, they use same components so the issue can be reproduced:

Here is the video of current flow https://recordit.co/XLmFwCfFZo

Here is the script I wrote to reproduce the issue:

const playwright = require('playwright');

(async () => {

    const browser = await playwright.chromium.launch({
        headless: false,
        // slowMo: 200,
    });
    const page = await browser.newPage({
        viewport: { width: 1400, height: 500 }
    });
    await page.goto('https://wetransfer.com');
    await page.click('.welcome__agree');
    await new Promise((done) => setTimeout(done, 1000));
    await page.goto('https://wetransfer.com');
    await page.click('.button--free');

    await new Promise((done) => setTimeout(done, 5000));
    await browser.close();
})();

Video of scripted flow: https://recordit.co/5emcL0zxwO

On the video you see that the new tab is opened insted of clicking the button
Try to change the height of viewport to see the different. If you make viewport larger - the behavior will be similar to expected.

aslushnikov added a commit to aslushnikov/playwright that referenced this issue Mar 10, 2020
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Mar 10, 2020
@aslushnikov
Copy link
Collaborator

@DavertMik nicee, thank you! I was able to reduce this to a nice small test case.

For the record: the root cause here is due to the incorrect input dispatching that we do on the chromium-side when dispatching input across iframes. We currently shortcut iframe picking in input_handler.cc using RenderWidgetHostInputEventRouter::GetRenderWidgetHostAtPoint - which is not correct. In fact, there are no other chromium clients for the method apart from us.

Instead, we should migrate onto RenderWidgetHostInputEventRouter::GetRenderWidgetHostAtPointAsynchronously so that we can properly dispatch events.

P.S. @DavertMik: you should be able to workaround this bug in chromium with --disable-site-isolation-trials flag.

@aslushnikov aslushnikov added bug browser-chromium upstream This is a bug in something playwright depends on, like a browser. labels Mar 10, 2020
@aslushnikov
Copy link
Collaborator

aslushnikov added a commit to aslushnikov/playwright that referenced this issue Apr 16, 2020
This roll includes:
- https://crrev.com/759486 - devtools(protocol): Input.dispatchMouseEvent to properly find target widget host

Fixes microsoft#1240
pavelfeldman pushed a commit that referenced this issue Apr 16, 2020
This roll includes:
- https://crrev.com/759486 - devtools(protocol): Input.dispatchMouseEvent to properly find target widget host

Fixes #1240
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browser-chromium upstream This is a bug in something playwright depends on, like a browser.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants