Open Bug 1673059 Opened 1 year ago Updated 6 months ago

Improve back/forward navigation for bfcache

Categories

(Testing :: Marionette, task, P3)

Default
task

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

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.

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)
You need to log in before you can comment on or make changes to this bug.