Is there a JS-exposed API to check BFcache's level?

[Hitoshi Yoshida]

Hi all,

I'm working to fix web tests that don't work with same-site BFcache.

And I have a test case that checks something doesn't match BFcache's behavior.

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/http/tests/misc/resource-timing-iframe-restored-from-history.html

Assuming we have few more similar test cases, I'd like to disable or skip them when same-site BFcache is enabled, but I can't find a way. (e.g. check the feature from JS code)

Do anyone know a good way to do it?

-- 

Hitoshi Yoshida (Peria)

email: pe...@chromium.org

[Hitoshi Yoshida]

Or can we forcibly disable pro-active same-site BF cache from test code, i.e. from JavaScript?

This is much better than detecting the feature is enabled.

2020年11月4日(水) 16:23 Hitoshi Yoshida <pe...@chromium.org>:

[Fergal Daly]

These web tests are going to fall into 3 groups

1 should not run if bfcache is on

2 doesn't really matter whether bfcache is on or off

3 should be tested with both

There is a 4th category which would be "should be run with bfcache forced on" however that can't apply to any of the existing tests.

#2 is simple, we just make it compatible with bfcache and we're done.

For #1 and #3, it's easy enough if we know that we have bots that will do 2 full runs with each of bfcache enabled and disabled. Is that the case? If so, we just need to make #1 end early when it detects that bfcache is on . For #3, we can make the test compatible with both or we can fork the test into a bfcache and no-bfcache versions that each exit early if appropriate.

Does that make sense?

F

--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAJnxdXBOr%2B0v7MNKy2E8UJwhE5q2TKjcRBKRkwaJQ9RA88%2B6og%40mail.gmail.com.

[Alexander Timin]

+1 to what Fergal said.

One interesting subcategory of #3 are tests which are specifically checking the behaviour when the back-forward cache is not enabled and that the history navigation page load is being handled correctly.

Overall they should be rare, but this test, based on the comment which says that the iframe restored from history should have a special behaviour, seems to be an interesting one.

Ideally we would run test twice, with and without bfcache and have two different sets of expectations.

However, I'm not very familiar with layout tests configurations and not sure how easy it actually is.

Disabling bfcache for this test seems like a good idea too. 

Answering specific questions:

- We can know whether a navigation was restored from bfcache or not via the event.persisted property of the pageshow's event.

- We have been talking about adding a JS API to clear the history and disable bfcache. +Rakina Zata Amni.

  

Alexander

[Hitoshi Yoshida]

Hi all,

Thank you for suggestions. Grouping in Fergal's reply makes sense.

IIRC, we can enable pro-active same-site back-forward cache in the command line, and thus I think VirtualTestSuites can help us.

If it works, we don't need specific JS APIs at the moment, but thank you for providing the information, Alexander.

2020年11月6日(金) 11:13 Alexander Timin <alt...@google.com>:

[Rakina Zata Amni]

FYI, there's a thread in the WPT repo about bfcache. We should probably gather all WPTs we fixed that are in category #1 and #3, and maybe reply in that thread a bit later if we do find compelling cases for 3 (testing with both bfcache on & off). Even if we don't have the bfcache opt-out API in the near future, maybe we can add some WPT-only-thing to disable bfcache? (not sure if it's possible :) )