I agree with Domenic. What's the status of the standardization effort of the 'BFCache-Opt-In' header?
On Thu, Aug 19, 2021 at 2:01 AM Domenic Denicola <dome...@chromium.org> wrote: > > > On Wed, Aug 18, 2021 at 9:14 AM Minoru Chikamune <chikam...@chromium.org> > wrote: > >> Contact emails >> >> bfcache-...@chromium.org >> >> Explainer >> >> >> https://docs.google.com/document/d/1PmUFTxTJN4n-WyWry4tQ96t5P9XXkgwFo9CiNeslZEg/edit >> >> Specification [updated since Android I2S] >> >> Back-forward cache (BFCache) is an already existing concept in HTML spec. >> The BFCache eligibility is referred to as “document salvageable state” [ >> spec >> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#concept-document-salvageable>], >> and the navigation steps like “unloading a document” [spec >> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#unload-a-document>] >> refers to BFCache as “keep document alive in a session history entry”. We >> have been actively improving BFCache in standards through writing >> guidelines <https://github.com/w3ctag/design-principles/pull/317> on how >> web platform features should interact with BFCache, filing and fixing >> current spec issues <https://github.com/whatwg/html/issues/5880>, and >> making it possible to test BFCache through WPTs >> <https://github.com/web-platform-tests/wpt/pull/28950> (+ writing the >> WPTs). >> >> Design docs [unchanged] >> >> >> https://docs.google.com/document/d/1jwzZx_hUqca6ALmK2G1aNcykhWM1Bh79zRZlUg5KKjQ/edit >> >> Summary >> >> Back-forward cache is a browser feature which improves the user >> experience by keeping a page alive after the user navigates away from it >> and reuses it for session history navigation (browser back/forward buttons, >> history.back(), etc) to make the navigation instant. The pages in the cache >> are frozen and do not run any javascript. >> >> We already shipped >> <https://www.chromestatus.com/feature/5815270035685376> this feature for >> Android >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/XS9VnYQoaQE>. We >> want to ship back-forward cache on desktop environments. >> >> Link to “Intent to Experiment” blink-dev discussion >> >> https://groups.google.com/a/chromium.org/g/bfcache-dev/c/6nKwd472yPI >> >> Is this feature supported on all six Blink platforms (Windows, Mac, >> Linux, Chrome OS, Android, and Android WebView)? >> >> No. >> >> We already shipped this feature for Android. >> >> We would like to proceed shipping of BFCache to Windows, Mac, Linux and >> Chrome OS platforms with this I2S. >> >> We do not have active plans to support Android WebView as the cost of >> integrating WebView embedding APIs with back-forward cache is too high, >> while history navigation optimisations have limited benefit for WebView >> given its nature. >> >> Debuggability [unchanged] >> >> Support for DevTools is planned >> <https://docs.google.com/document/d/1AERry3jkVMk1OHtka_1Q3ThC-9OIMxUxZN4cPH9hi54/edit?usp=sharing> >> and currently being implemented. With this addition, web developers can see >> a list of reasons why their page is not eligible for bfcache. >> >> Blink component >> >> UI>Browser>Navigation>BFCache >> >> Search tags >> >> bfcache >> <https://www.chromestatus.com/features/6520669959356416#tags:bfcache> >> >> RisksInteroperability and Compatibility [updated since Android I2S] >> >> Interoperability - Low, given that we have been shipping it on Android, >> along with other vendors. >> >> Gecko: Shipping >> <https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching> >> >> WebKit: Shipping >> <https://webkit.org/blog/427/webkit-page-cache-i-the-basics/> >> >> Chrome Android: Shipping >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/XS9VnYQoaQE> >> >> Since shipping on Android, we have made significant progress on the >> standardization front. The W3C TAG agreed >> <https://github.com/w3ctag/design-reviews/issues/628#issuecomment-837570345> >> to put BFCache considerations to their Design Principles guideline [pull >> <https://github.com/w3ctag/design-principles/pull/317>, pull >> <https://github.com/w3ctag/security-questionnaire/pull/128>], so all >> future APIs will have BFCache support explicitly specified. The BFCache >> interaction is now part of OWP Security Review as well. >> >> Compatibility - Low. >> >> To minimize compatibility risk, we continue to take the cautious approach >> of not caching pages when faced with uncertainty. >> >> Notable difference to the Android launch is unload handlers. For this >> release, we mitigated the risk by requiring the `BFCache-Opt-In: unload` >> response header specified by the page author to put pages with unload >> handlers to BFCache. We will not fire unload events when the page is >> BFCached. This was less of an issue on Android, since the unload handlers >> were not reliable on Android anyway. Desktop Chrome also didn’t guarantee >> the unload handler as well, but it is fired most of the time that many >> desktop websites rely on it. Again, we don’t BFCache such pages without the >> page authors’ consent in this release, but we might want to revisit this in >> the future (related: Firefox experiment >> <https://groups.google.com/a/mozilla.org/g/dev-platform/c/3pQRLPZnQgQ/m/dsA1w4iiAwAJ>). >> An enterprise policy for disabling back-forward cache is available. >> > > This header seems like a significant interop risk, as I'm not aware of any > specification for it, or signals from other vendors. > > It would be good to get a specification pull request written to HTML, > appropriate WPT coverage, and ideally some agreement from other vendors > that they want to go this route, before shipping. > > >> >> Ergonomics [unchanged] >> >> N/A. Websites don’t have to do anything (i.e. they will benefit from >> BFCache automatically). >> >> Activation [unchanged] >> >> Mostly N/A. >> >> Back-forward cache will work without any developer activation, but web >> developers can make their pages bfcache-friendly with some extra work. This >> would further increase the cache hit rate and improve the user experience. >> We have published guidance on https://web.dev/bfcache/. Also we'll be >> working with partners and interested parties on this. >> >> Security [new!] >> >> See these one-pagers >> >> - >> >> Privacy one-pager: BFCache Desktop: Privacy Explainer >> >> <https://docs.google.com/document/d/1x-Z291LQxHNJw5uyvkW6gjEAfgTmkm1zLv3whKjIyXs/edit> >> - >> >> Security one-pager: BFCache Desktop: Security Explainer >> >> <https://docs.google.com/document/d/1o7FZ58s8m1o5w9Bt-8vWNNbTDRidGV_BIrHaogU8d_M/edit> >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> We are actively making progress in the area. >> >> - >> >> List of issues to be covered by tests >> <https://github.com/whatwg/html/issues/5880> >> - >> >> Discussions on test framework APIs needed for BFCache tests are >> ongoing around WPT PR >> <https://github.com/web-platform-tests/wpt/pull/28950> and WPT RFCs >> (86, 88-91) >> >> <https://github.com/web-platform-tests/rfcs/pull/86#issuecomment-887783246> >> . >> - >> >> We have more draft WPTs >> <https://chromium-review.googlesource.com/c/chromium/src/+/2798554/> >> that will be ready for code review once the discussions on test framework >> is settled. >> >> >> Tracking bug >> >> https://crbug.com/1171298 >> >> Launch bug >> >> https://crbug.com/1196523 >> >> Link to entry on the feature dashboard <https://www.chromestatus.com/> >> >> https://chromestatus.com/feature/6279906713403392 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVDLEkNUVt%2Bk4u6w0xzL-XHovRqtq%2BUx6atJdeo0-rBZaUw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVDLEkNUVt%2Bk4u6w0xzL-XHovRqtq%2BUx6atJdeo0-rBZaUw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_dJY4HC%2BNKOH62Eh4RRE-z6FnFXqXXEDBKPKJB49ZOiw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_dJY4HC%2BNKOH62Eh4RRE-z6FnFXqXXEDBKPKJB49ZOiw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- TAMURA Kent Software Engineer, Google -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqF41sWHbcVKEWj4okjKDT9QpmH8gt3y_txos4k9yRSP0A%40mail.gmail.com.
