Excluding the "BFCache-Opt-In" part sounds good. LGTM1.
On Tue, Aug 24, 2021 at 12:26 PM Minoru Chikamune <chikam...@chromium.org> wrote: > 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 >> >> >> -- 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/CAGH7WqEr1NyrZ%3DaHfYLppAFuJDwdyruXn8aEMP%2BofkmaSWhS-g%40mail.gmail.com.
