specifying BFCache interactions with window.open and browsing context groups

[fergald]

For example, page1 calls window.open() to create a new page in the same browsing context.

There are 2 cases

• the new page is scriptable
• the new page is only messageable

Chrome disallows both, I'm told that Firefox allows something here and Safari I'm not sure. I tried testing with FF but couldn't trigger BFCache at all. It would be good to know the intended behaviour.

It seems like in the scriptable case, if the page goes into BFCache, then this must be visible to the other page. So we should spec what the visible impact is when a browser chooses to allow it or that it's disallowed.

Similarly in the messageable case, if we are not going to disallow it in the spec then we should spec what happens. Is it

• the page still has a valid window reference and messages are queued?
• the window reference become invalid? What happens when the page is restored from the cache?

@rakina @domenic @cdumez @annevk @rniwa

[rakina]

I think last year @mystor mentioned something about the Firefox support for this in this comment but looks like there's some desire to follow Chrome here (not cache when the browsing context group contains > 1 top level pages). I think it's reasonable, and would be a good thing to add to the spec.

[mystor]

Currently in Firefox with Fission disabled it is possible to put a page into BFCache while it has opener relationships (>1 toplevel in it's BCG), but we're planning to switch to a new BFCache architecture later this year which doesn't allow BFCaching documents with opener relationships anymore.

(cc @smaug----)

[fergald]

Currently in Firefox with Fission disabled it is possible to put a page into BFCache while it has opener relationships (>1 toplevel in it's BCG), but we're planning to switch to a new BFCache architecture later this year which doesn't allow BFCaching documents with opener relationships anymore.

Thanks, I'm curious how FF handles the 2 cases I described above.

[mystor]

I don't think gecko distinguishes between a "scriptable" vs. "messageable" popup window created with window.open. We always (unless noopener is set) open a window with a same-origin initial about:blank document, and then navigate it to the final requested URL. With the new BFCache approach we're taking with Fission, all BCGs with multiple toplevels have BFCache blocked, and we don't treat them differently.

The existing behaviour with Fission disabled is to allow caching documents which are visible to other webpages, so long as the unload listener isn't present. This is unfortunately quite visible to webpages and can have some quite strange impacts, which is one of the reasons we're moving away from it.

[fergald]

Thanks. I was mostly curious if you had some good remedy to the "quite strange impacts". So maybe we should be aiming to spec that we can't cache in this case.

[smaug----]

In practice we haven't seen "strange impacts" affecting web pages too often. But the old implementation does do some perhaps unexpected stuff - like if you start modifying a document which is in bfcache, it gets evicted.

[fergald]

I would expect that reports of strange impacts would be rare but unless there's a reasonable way to spec what's supposed to happen, I would like to spec that it must not happen (and test that).