Open Bug 1673059 Opened 4 years ago Updated 14 days ago

Improve back/forward navigation when bfcache is disabled

Categories

(Remote Protocol :: Marionette, task, P3)

Default
task

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.

Blocks: 1664165
See Also: → 1683841
Depends on: 1421628

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.

Depends on: 1704697
Flags: needinfo?(james)

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 :)

Flags: needinfo?(james)

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.

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.

Whiteboard: [webdriver:triage]

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.

Summary: Improve back/forward navigation for bfcache → Improve back/forward navigation when bfcache is disabled
Whiteboard: [webdriver:triage] → [webdriver:backlog]
Product: Testing → Remote Protocol
No longer blocks: 1664165
You need to log in before you can comment on or make changes to this bug.