Relax requirement to not always wait for a page navigation as triggered by Element Click

[whimboo]

Right now the WebDriver spec for Element Click requires a Try to wait for navigation to complete. Given the uncertainty when a navigation actually gets started after the click event, it's unclear how long an implementation should actually wait for it. If the duration is too short a page load will be missed. And if it's too long, the response of the Element Click command is delayed by a certain amount of milliseconds, eg. in geckodriver we currently use 200ms as cut-off given that gave the most reliable results. Further it's not only the click command that could trigger a navigation, but also Element Send Keys. But that command doesn't have this requirement because it would massively slow down the processing if each key is getting send separately.

As far as I can remember we added the navigation check to help the transition from the old driver to WebDriver given that formerly that check was in-place and a lot of users relied on it. Nowadays pages are way more dynamic and especially with people using Puppeteer a huge performance loss can be seen. Eg. see https://dev.to/pjcalvo/webdriver-vs-chrome-devtools-speed-test-441h, where I will soon comment on.

As such I wonder if we could lift-up that requirement and maybe bind it to a capability? That way we could allow users to get the maximum performance out of each WebDriver command without having to specifically set the Page Load Strategy to None (which would affect all the navigation commands).

CC'ing some folks to get their opinion... @AutomatedTester, @shs96c, @jgraham, @JohnChen0, @burg, @thejohnjansen, @jimevans.

[jgraham]

I'd assume the correct approach here is to wait until the click event has been processed (e.g. by adding a handler for the click event like await new Promise(resolve => target.addEventListener("click", setTimeout(resolve, 0)));). That avoids an unnecessary timeout but handles the case of the click handler causing a navigation to start.

That said, such a change might not be compatible with existing tests, in which case we might just need to accept that this will be slow in the HTTP variant of WebDriver.

[titusfortner]

I don't know, I recommend that testers always ignore the Page Load status, and to focus synchronization efforts on the state of the element they want to interact with. I actually think suggesting users toggle Page Load Strategy to None is the best way to handle this if performance is an issue; since they are probably already ignoring it if they are working with a SPA, etc.

[jgraham]

Presumably this isn't about the case where there actually is a navigation; it's about the case where we are waiting after the click to check if it's going to cause a navigation.

It's probably also true that the actions API doesn't have this requirement, so if this is the limiting factor in the benchmark there's probably a simple fix that way.