1673059 - Improve back/forward navigation when bfcache is disabled

Status: NEW

(Remote Protocol :: Marionette, task, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

As noticed while working on bug 1672758 our navigation code hangs when pages are going into bfcache for back/forward navigation. This can easily be reproduced with the following Marionette test:

        self.marionette.navigate(inline("<p>foo"))
        self.marionette.navigate(inline("<p>bar"))
        self.marionette.navigate(inline(iframe("<p>bar")))
        frame = self.marionette.find_element(By.TAG_NAME, "iframe")
        self.marionette.switch_to_frame(frame)
        self.marionette.go_back()

This is not a regression from any recent code changes and I can reproduce even with Firefox 68ESR.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

With the fix on bug 1704697 we got already some good improvements.

Nevertheless the example from comment 0 is still failing. Having a further look this seems to actually be a bug in the WebDriver HTTP spec.
So what happens here... The first two navigation commands load just a single page, while the third navigation loads a page with a frame. Switching to that frame and calling Back will put the page into bfcache and a pagehide event is received. But there is never coming in a pageshow event for that frame, but only for the top-level browsing context, which we should not switch to given by the spec:

https://w3c.github.io/webdriver/#back

If the previous step completed results in a pageHide event firing, wait until pageShow event fires or for the session page load timeout milliseconds to pass, whichever occurs sooner.

As such in such conditions we always run into a page load timeout.

James, not sure if that's something we still want to fix in the HTTP spec or only make it work correctly in the BiDi spec.

Comment 2

[James Graham [:jgraham]]

I assume step 4 is intended to be interpreted as "a pageHide event firing on the top level browsing context". But actually I wonder if that's right either; what happens if the frame itself is navigated and then we go back. In that case I assume the frame gets a pageshow event, but I'm not sure off the top of my head if we get one for the top level context. This will all be easier in bidi where we don't plan to handwave this stuff, but actually define hooks in HTML :)

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

To actually create tests that do not use bfcache we have two methods:

1. Bind eg. a new RTCPeerConnection() to the window object which would not allow the page to enter bfcache.

2. Using the Cache-Control directive set to no-store.

Given that we don't have the above set for any of our current tests in wdspec we should actually test all the commands with bfcache active if the browser supports it.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Lets discuss if we should at least have some tests to cover the non-bfcache navigation scenarios especially around the checks for element staleness or no such element.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

There might be quite a good number of sites that will try to disable bfcache by setting an unload handler. As such we should have tests for the bfcache disabled at some time but won't have to do it now given that no user reported issues yet.