We respect the API OWNER feedback that the status of BFCache-Opt-In header spec would cause more interoperability issues. We actually did plan on standardizing the header after Domenic raised a similar concern internally a while back, and already prepared the explainers etc for it, but it got accidentally dropped amidst the thick of things our team was doing to ensure the Desktop experiment goes smoothly. Then when the time came to draft our I2S, everyone thought the opt-in header had actually gone through the standardization process as planned before, and here we are. Apologies if this came off as not wanting to standardize something before shipping it, it’s definitely not our intention.
Now, let us retract the "BFCache-Opt-In" header part from the I2S. We would appreciate your reviews under the new condition. Specifically, we would like to request shipping a version of BFCache for Desktop that forbids all pages with an unload handler to enter BFCache. The following paragraph from the original post: 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. Should now read: To mitigate the risk of breaking unload events, in this I2S, we would like to request shipping BFCache on Desktop which does not cache pages with unload handlers. (We plan to standardize and file a separate I2S for making pages with unload handlers BFCache-eligible in the future.) chikamune@, kouhei@, and rakina@ On Mon, Aug 23, 2021 at 4:54 PM TAMURA, Kent <tk...@chromium.org> wrote: > 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/CAEy%2BVD%2B%2BDATTZ57conix7YpGvL1Sp%2BSSmPMqYA-brDh6MXMzjg%40mail.gmail.com.
