Scroll listeners can make click events unreliable

Steps to reproduce

Tell us about your environment:

Puppeteer version: 1.12.2 Platform / OS version: Windows 10 URLs: Enterprise Domain so I can’t share 😢 Node.js version: v8.12.0

What steps will reproduce the problem?

1. Be on any page with a significant scroll listener.
2. await element.click(options).
3. Click event might not fire, or at least not before a different function runs and moves the scrollbar again.

What is the expected result?

I mean, it’s understandable that the click event doesn’t fire some time (or, again, just doesn’t run in a timely manner), but as things are now, we need some way to be able to do some logic to wait for the page to stabilize between the scroll event and the click event.

For example, using a private property on the element handler can fix this (this is actually what I’m doing in the meantime, while I wait for an alternative):

export default async function safeClick(elHandle = ctx.page, ...args) {
    // an actual private function in the puppeteer api while researching this bug
    await elHandle._scrollIntoViewIfNeeded();
    await myCheckStabilizationFunction();
    await expect(elHandle).toClick(...args);
}

What happens instead?

I have no way to insert stabilization logic between puppeteer attempting to scroll the page and attempting to click the element.

[Aaron-Pool]

@aslushnikov I’m not entirely sure that’s true.

I’m writing e2e acceptance test scripts for a web application. I don’t so much care about performance, as much as the highest possible reliability and adaptability to changing conditions such as server speed, dom restructuring, implementation changes, etc. To do this I have a wrapper function for all browser interactions that ensures the page is totally stable before attempting the operation, to ensure the operation occurs as expected. But I’m also recording all of these tests so that, if any of the QA engineers have concerns about a false negative or positive, they can watch the test and skip to the relevant portion.

That being said, if the screen is repeatedly jumping around unnecessarily because I called scrollIntoView on every user interaction, it will make it more difficult to understand what’s happening.

I understand this isn’t really your problem, or anything you’re responsible to fix. Just explaining the circumstance that makes manually calling _scrollIntoViewIfNeeded desirable.

[aslushnikov]

That being said, if the screen is repeatedly jumping around unnecessarily because I called scrollIntoView on every user interaction, it will make it more difficult to understand what’s happening.

@Aaron-Pool makes perfect sense. I’d steal our implementation then to make sure it doesn’t disappear from the private API (there are no plans though).

Let’s postpone exposing _scrollIntoViewIfNeeded to public API until there are more requests.