Clicks are assumed to be asynchronous. Therefore the browser can return whenever it wants to, perhaps before any click handlers have fired or JS being processed. Tests are required to determine when it's safe to proceed.

This is largely because there's no way of telling beforehand whether a click will cause a page load or not.

*** Bug 24960 has been marked as a duplicate of this bug. ***

PageLoadingTest.testShouldTimeoutIfAPageTakesTooLongToLoadAfterClick() requires that the driver waits (and eventually times out) after clicking on a link:

https://github.com/SeleniumHQ/selenium/blob/01399fffecd5a20af6f31aed6cb0043c9c5cde65/java/client/test/org/openqa/selenium/PageLoadingTest.java#L419

Section 6 of the current spec says "For commands that cause a new document to load...return after the load event fires on the new page" (for a normal page loading strategy), but I'm not sure if this applies only to the navigation commands in that section or any command that causes a new document to load:

https://w3c.github.io/webdriver/webdriver-spec.html#navigation

But Simon's also right in that a click is asynchronous and it's not easy to tell if a click handler will navigate to a new page or not. In the worst case, a click handler might do an animation (or something else that takes time) before navigating.

It'd be good if there was a decision on exactly what should happen here.

I am for simplicity and against spec requirements that I don't believe that vendors will thoroughly implement. So I +1 Comment 1.

Also https://github.com/joshbruning (from whom we will hear more and more) as well as jleyba and other people have different good ideas in this area. Such as WebDriver exposing hooks that app under test (e.g. web ui frameworks) can use to tell that page has finished loading. Ideas that might make it easy to implement on the WebDriver side and easy for web ui frameworks (or just web apps) to integrate with - making test code free of explicit waits.

(Those kinds of things could go in Level 2 and extensions of the standard)

This isn't an extension: it's already defined behaviour. Normal clicks should use the page loading strategy to tell if the driver needs to wait. Advanced user interaction clicks need not do so. 

Getting the AUT to help provide hints is nothing to do with webdriver and everything to do with good testing strategy.

I know that pageLoadStrategy is currently specified in the draft.
I also know that pageLoad[ing]Strategy strategy existed in Selenium/WebDriver for a while.

However I don't know of a driver that would fully implement all of the strategies without missing and buggy behavior (am I missing one?). That is why I support dropping pageLoadStrategy capability from the spec while we can. (and also for the reasons I mentioned in Comment 4)

I read your Comment 1, Simon, as one against the notion of pageLoadStrategy (for both normal clicks and advanced user interactions), perhaps I misunderstood.

>> Getting the AUT to help provide hints is nothing to do with webdriver and everything to do with good testing strategy.

(sorry for bringing that up, this bug isn't right place for this discussion) 

It may have something to do with WebDriver if we want WebDriver commands to never return control before the "page is fully loaded" in the Whole sense: by the definition of the application under test. And I think we do. We will discuss this separately when time will come...

So one way to handle this that makes sense is to let the event loop spin until any event handlers that would be fired by the click event have run. This may simply be equivalent to setTimeout(function() {return_from_click_command()}, 0), but I will check with DOM.

action item from TPAC Lisbon