LGTM3 On Thu, Aug 26, 2021 at 8:04 AM Domenic Denicola <dome...@chromium.org> wrote:
> Non-owner LGTM; thanks for splitting the intent in that way! I look > forward to reviewing the HTML spec PR for the header, and as HTML editor am > really happy with the other bfcache standardization work the team has been > doing. > > On Thu, Aug 26, 2021 at 3:32 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> 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/CAM0wra-WCeUjo237A3W8_qVk-GZipa3euhhPA3fcJe%3DPctyHXA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-WCeUjo237A3W8_qVk-GZipa3euhhPA3fcJe%3DPctyHXA%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/CAOMQ%2Bw_hmXE9%3DpXCnuvXD2BdZ6F8c33HcYZGQDGF1D9sdud8BA%40mail.gmail.com.
