Improve back/forward navigation when bfcache is disabled
Categories
(Remote Protocol :: Marionette, task, P3)
Tracking
(Not tracked)
People
(Reporter: whimboo, Unassigned)
References
(Depends on 1 open bug)
Details
(Whiteboard: [webdriver:backlog])
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.
Reporter | ||
Comment 1•3 years ago
|
||
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•3 years ago
|
||
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 :)
Reporter | ||
Comment 3•2 years ago
|
||
To actually create tests that do not use bfcache we have two methods:
-
Bind eg. a new
RTCPeerConnection()
to the window object which would not allow the page to enter bfcache. -
Using the
Cache-Control
directive set tono-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.
Reporter | ||
Comment 4•2 years ago
|
||
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.
Reporter | ||
Comment 5•2 years ago
|
||
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.
Updated•2 years ago
|
Description
•