LGTM2 I think that the header can be useful to help align BFCache behavior across engines. I'm looking forward to standardization efforts on that front.
On Wednesday, August 25, 2021 at 2:26:27 AM UTC+2 Kent Tamura wrote: > 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/d1021f60-b645-4d55-8c28-854a253ff874n%40chromium.org.
