Thanks Domenic for bringing up the concerns! - I found performance-navigation-timing-navigation-failure.tentative.window.js <https://github.com/web-platform-tests/wpt/blob/master/performance-timeline/not-restored-reasons/performance-navigation-timing-navigation-failure.tentative.window.js> which seems like it needs to be updated from "error-document" to "navigation-failure". That's worth looking into in case it means the implementation is also not yet updated.
> Updated all the strings to match the spec-defined strings. - I also found that the Chromium test directory is full of -expected.txt files <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/abort-block-bfcache.window-expected.txt?q=NotRestoredReasonDetails&ss=chromium%2Fchromium%2Fsrc&start=21>, which seem to match up with the failures on wpt.fyi <https://wpt.fyi/results/performance-timeline/not-restored-reasons?label=master&label=experimental&aligned&q=performance-timeline%2Fnot-restored-reasons>. Will those be addressed before shipping? > Now the failing tests and the expected files are down to three. 1) parser-aborted We currently block with different reason("loading"), as we haven't worked on differentiating loading vs parser getting aborted. 2) navigation-failure We do report "navigation-failure" when the document errors(implementation <https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/back_forward_cache_impl.cc;drc=f4a00cc248dd2dc8ec8759fb51620d47b5114090;bpv=1;bpt=1;l=912>), but somehow the test only reports "http-status-not-ok" which is the chrome internal reason. I will look into this more. 3) weblock Chrome currently blocks with another reason here (masked), so this failure will not go away. Maybe I should make WPTs to test if the expected reason exists in the list, instead of checking the complete list. - I found a nonstandard toJSON() in NotRestoredReasonDetails <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/not_restored_reasons.idl;l=12;drc=6211b1c8268b239694bd84d7a99e508a15dc6dea> in Chromium. Was the intent to specify that? > Added this to the spec, thanks! - Can you confirm that Chromium does not plan to ship any nonstandard not restored reason strings, beyond the specified "fetch", "navigation-failure", "parser-aborted", "websocket", "lock", and "masked"? > We plan to add user-agent specific reasons to the spec in the may-block section. This is the draft PR <https://github.com/whatwg/html/pull/10154/files> (have't added the explanation for each reason yet). Is it okay to ship while we work on the follow-up PR? On Wednesday, February 7, 2024 at 2:33:04 PM UTC+9 Domenic Denicola wrote: > On Wed, Feb 7, 2024 at 12:51 PM Fergal Daly <fer...@google.com> wrote: > >> On Wed, 7 Feb 2024 at 12:26, Domenic Denicola <dom...@chromium.org> >> wrote: >> >>> >>> >>> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly <fer...@google.com> wrote: >>> >>>> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola <dom...@chromium.org> >>>> wrote: >>>> >>>>> I am happy with the spec progress here and don't think it's a >>>>> significant blocker for the Intent at this point. >>>>> >>>>> On the tests and implementation: >>>>> >>>>> - I found >>>>> performance-navigation-timing-navigation-failure.tentative.window.js >>>>> >>>>> <https://github.com/web-platform-tests/wpt/blob/master/performance-timeline/not-restored-reasons/performance-navigation-timing-navigation-failure.tentative.window.js> >>>>> >>>>> which seems like it needs to be updated from "error-document" to >>>>> "navigation-failure". That's worth looking into in case it means the >>>>> implementation is also not yet updated. >>>>> - I also found that the Chromium test directory is full of >>>>> -expected.txt files >>>>> >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/abort-block-bfcache.window-expected.txt?q=NotRestoredReasonDetails&ss=chromium%2Fchromium%2Fsrc&start=21>, >>>>> >>>>> which seem to match up with the failures on wpt.fyi >>>>> >>>>> <https://wpt.fyi/results/performance-timeline/not-restored-reasons?label=master&label=experimental&aligned&q=performance-timeline%2Fnot-restored-reasons>. >>>>> >>>>> Will those be addressed before shipping? >>>>> - I found a nonstandard toJSON() in NotRestoredReasonDetails >>>>> >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/not_restored_reasons.idl;l=12;drc=6211b1c8268b239694bd84d7a99e508a15dc6dea> >>>>> in >>>>> Chromium. Was the intent to specify that? >>>>> - Can you confirm that Chromium does not plan to ship any >>>>> nonstandard not restored reason strings, beyond the specified "fetch", >>>>> "navigation-failure", "parser-aborted", "websocket", "lock", and >>>>> "masked"? >>>>> >>>>> I don't know specifically what is there right now but I would expect >>>> that we will ship others. E.g. BroadcastChannel blocks BFCache on Chrome >>>> and Mozilla but not WebKit and there is currently disagreement. Why would >>>> it be better to show "masked" for that case? >>>> >>> >>> The idea is to follow the standards and not ship nonstandard behavior. >>> The current spec PR actually only allows sending "masked" in the >>> cross-origin case, and doesn't allow sending it for BroadcastChannel. If >>> the intention is to send some value in the BroadcastChannel case (which is >>> this >>> part of the spec >>> <https://html.spec.whatwg.org/multipage/browsing-the-web.html#document-state:~:text=User%20agents%20may,keeping%20it%20cached.>) >>> >>> then that needs to be specified in the spec PR before shipping such a value >>> in Chromium. >>> >> >> BFCaching is never required by spec. That means any browser can block >> BFCache at any time, for any reason and still be in spec. >> > > Yes. But a browser cannot create values for the NotRestoredReasonDetails's > reason property which are not in the spec, while staying spec-compliant. > This is similar to how we cannot have, e.g., DOMException's name property > returning arbitrary values; we instead document them all in the spec > <https://webidl.spec.whatwg.org/#idl-DOMException-error-names>, and then > document that some of them may be thrown in implementation-specific > circumstances (example <https://html.spec.whatwg.org/#killing-scripts>). > > >> >> I think what's missing is that said we would maintain a registry of >> reasons that were not in the spec so that when we block for unspecced >> reasons, we don't proliferate a bunch of undocumented names. >> >> I'm not sure how to express that in the spec, >> > > We discussed how to do so upthread: > https://groups.google.com/a/chromium.org/g/bfcache-dev/c/ufQx6r6su6U/m/vyQM9nGHAwAJ > > > > > >> >> F >> >> >>> >>> >>>> >>>> F >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo <yu...@google.com> wrote: >>>>> >>>>>> This is now ready to ship, now that we have all the approvals on the >>>>>> ChromeStatus >>>>>> <https://chromestatus.com/feature/5684908759449600?gate=6535221965488128>and >>>>>> >>>>>> the spec draft <https://github.com/whatwg/html/pull/9360> is close >>>>>> to agreement. >>>>>> >>>>>> Can you please take a look at this again? >>>>>> Thanks! >>>>>> >>>>>> On Saturday, September 30, 2023 at 5:00:51 AM UTC+9 Chris Harrelson >>>>>> wrote: >>>>>> >>>>>>> Please also make sure to complete all of the other shipping gate >>>>>>> reviews >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/bqvB1oap0Yc/m/YlO8DEHgAQAJ> >>>>>>> . >>>>>>> >>>>>>> Thanks! >>>>>>> Chris >>>>>>> >>>>>>> On Thu, Aug 10, 2023 at 8:46 AM 'Yuzu Saijo' via blink-dev < >>>>>>> blin...@chromium.org> wrote: >>>>>>> >>>>>>>> Sounds good, I will create a list on the explainer >>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md> >>>>>>>> >>>>>>>> for the "may block" reasons then. >>>>>>>> >>>>>>>> Re: exposing NotRestoredReasons interface instead of object in idl: >>>>>>>> I'm working on the implementation in this CL >>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4770594> >>>>>>>> . >>>>>>>> This might be a basic question, but is there any difference on how >>>>>>>> to call the API from users' perspective, when the exposed attribute is >>>>>>>> an >>>>>>>> interface vs object? >>>>>>>> >>>>>>>> On Thursday, August 10, 2023 at 10:06:49 AM UTC+9 >>>>>>>> dom...@chromium.org wrote: >>>>>>>> >>>>>>>>> On Wed, Aug 9, 2023 at 6:44 PM Fergal Daly <fer...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola < >>>>>>>>>> dom...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> I think specifying these reasons is important. As noted in the >>>>>>>>>>> linked issue >>>>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/issues/2>, >>>>>>>>>>> I think the end goal should be: >>>>>>>>>>> >>>>>>>>>>> - Every reason that a browser ever emits, is found in a >>>>>>>>>>> specification somewhere. (It doesn't have to be the HTML spec, >>>>>>>>>>> e.g. the >>>>>>>>>>> speech synthesis reason could live in the speech synthesis spec.) >>>>>>>>>>> >>>>>>>>>>> There's no intrinsic reason for speech synthesis to block >>>>>>>>>> BFCache. It just happens that Chrome blocked it. There's no spec >>>>>>>>>> reason for >>>>>>>>>> unload to block BFCache, in fact the spec says that it doesn't. >>>>>>>>>> >>>>>>>>>> I think it's good for us to have agreed names, e.g. >>>>>>>>>> "unload-event-handler". Should we put into various specs "if an >>>>>>>>>> implementer >>>>>>>>>> chooses to block BFCache because X has been used, they should use >>>>>>>>>> the >>>>>>>>>> reason `Y`"? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - If browsers prevent bfcache restoration for a reason not >>>>>>>>>>> found in a spec, it is always translated to a standardized >>>>>>>>>>> reason such as >>>>>>>>>>> "unknown". >>>>>>>>>>> >>>>>>>>>>> This avoids the usual interop problems with vendor-specific >>>>>>>>>>> extensions to the web platform, such as: no clear specification for >>>>>>>>>>> what >>>>>>>>>>> strings to use; no clear point at which the reason is added to the >>>>>>>>>>> document's reasons list; etc. Although you claim these reasons are >>>>>>>>>>> idiosyncratic to Chrome, that won't necessarily be the case; e.g. >>>>>>>>>>> Firefox >>>>>>>>>>> has unload handler as a reason, and I suspect most user agents have >>>>>>>>>>> memory >>>>>>>>>>> limitations or similar. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Chrome has over 100 reasons. I'd say at least 50 of them are >>>>>>>>>> actionable such that you wouldn't want to lump them into an opaque >>>>>>>>>> "unknown" category. >>>>>>>>>> >>>>>>>>>> I do not relish the idea of updating 50 places in spec to insert >>>>>>>>>> a name to be used if you decide to block. >>>>>>>>>> >>>>>>>>>> How about maintaining a central list of reasons with low friction >>>>>>>>>> to add new reasons even if they are browser-specific? The cases >>>>>>>>>> where you >>>>>>>>>> *must* block should still be inline in spec (and also on the >>>>>>>>>> list), >>>>>>>>>> >>>>>>>>> >>>>>>>>> That sounds great to me. We should probably make this separation >>>>>>>>> clear in the spec, e.g. the "must" list will have cross-references >>>>>>>>> you can >>>>>>>>> follow, whereas the "may" list ends up only being cross-referenced >>>>>>>>> from >>>>>>>>> some generic location like >>>>>>>>> https://html.spec.whatwg.org/multipage/browsing-the-web.html#note-bfcache:~:text=User%20agents%20may,keeping%20it%20cached. >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> F >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We could have a discussion about allowing vendor-specific >>>>>>>>>>> information in the API *in addition* to the standardized >>>>>>>>>>> reasons. For example, we could have one of the standardized reasons >>>>>>>>>>> be >>>>>>>>>>> "user-agent-specific", and then add an additional field >>>>>>>>>>> userAgentSpecificInfo. But I would like to see significantly more >>>>>>>>>>> discussion with other vendors before going that route. >>>>>>>>>>> >>>>>>>>>>> On Tue, Aug 8, 2023 at 9:56 PM Yuzu Saijo <yu...@google.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> +bfcache-dev >>>>>>>>>>>> >>>>>>>>>>>> I was talking to Fergal today and discussed this, and I am not >>>>>>>>>>>> sure about adding browser-specific reasons to the spec. >>>>>>>>>>>> For example, some reasons like "speech synthesis API is used" / >>>>>>>>>>>> "unload handler" are completely specific to Chrome, and it doesn't >>>>>>>>>>>> really >>>>>>>>>>>> make sense to add them to the spec, even with the namespace >>>>>>>>>>>> (x-speechsysthesis / x-unloadhandler). >>>>>>>>>>>> Maybe we can document the reasons somewhere in a shared list >>>>>>>>>>>> but not in the spec? >>>>>>>>>>>> >>>>>>>>>>>> I think the API would be more useful if it can give as much >>>>>>>>>>>> information as possible, not limited to the specced reasons. >>>>>>>>>>>> Please let me know what you think! >>>>>>>>>>>> >>>>>>>>>>>> Yuzu >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, August 3, 2023 at 12:39:17 PM UTC+9 Yuzu Saijo >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the delayed response. >>>>>>>>>>>>> >>>>>>>>>>>>> *> there doesn't appear to be any NotRestoredReasons interface >>>>>>>>>>>>> defined in Chromium?* >>>>>>>>>>>>> Let me address this implementation and delay the shipping >>>>>>>>>>>>> until the chromium implementation matches the proposed spec. >>>>>>>>>>>>> Thanks for >>>>>>>>>>>>> pointing it out! >>>>>>>>>>>>> Same for WPT. I will add tests for all the standardized >>>>>>>>>>>>> reasons. >>>>>>>>>>>>> >>>>>>>>>>>>> *> Can you confirm that you're only shipping the specified >>>>>>>>>>>>> four?* >>>>>>>>>>>>> We do have ~50 not restored reasons, and in theory we will be >>>>>>>>>>>>> able to remove most of them except for the standardized four >>>>>>>>>>>>> reasons. >>>>>>>>>>>>> However, in reality it will take time for us to support all >>>>>>>>>>>>> the reasons and we need to keep blocking on them for a while. >>>>>>>>>>>>> In the meantime, our plan was to expose the non-standardized >>>>>>>>>>>>> reasons too, but in a way that's distinguishable from >>>>>>>>>>>>> standardized reasons as >>>>>>>>>>>>> you suggested here >>>>>>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/issues/2> >>>>>>>>>>>>> . >>>>>>>>>>>>> I realized that we need to add browser specific reasons to the >>>>>>>>>>>>> spec as well. Let me add that and send a review request again. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> Yuzu >>>>>>>>>>>>> On Thursday, July 13, 2023 at 12:07:05 PM UTC+9 >>>>>>>>>>>>> dom...@chromium.org wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Also, checking the tests, it seems like the >>>>>>>>>>>>>> currently-implemented reasons don't match the spec. E.g. this >>>>>>>>>>>>>> test >>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/performance-navigation-timing-bfcache-reasons-stay.tentative.window.js> >>>>>>>>>>>>>> requires >>>>>>>>>>>>>> the reason to be "WebSocket", but the specification says >>>>>>>>>>>>>> "websocket" >>>>>>>>>>>>>> (lowercase). I couldn't find tests for the other three reasons... >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jul 13, 2023 at 12:04 PM Domenic Denicola < >>>>>>>>>>>>>> dom...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have some questions about how well the implementation here >>>>>>>>>>>>>>> matches up with the spec. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, there doesn't appear to be any NotRestoredReasons >>>>>>>>>>>>>>> interface defined in Chromium? The relevant attribute on >>>>>>>>>>>>>>> PerformanceNavigationTiming returns object? >>>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_navigation_timing.idl;l=33?q=NotRestoredReasons%20file:%5C.idl&ss=chromium>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That seems like a problematic mismatch... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Second, I can't find exactly where the list of >>>>>>>>>>>>>>> script-exposed not restored reasons are. But, I'll note that >>>>>>>>>>>>>>> Chromium >>>>>>>>>>>>>>> seems to have ~50 such reasons >>>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:content/browser/renderer_host/back_forward_cache_metrics.h;drc=6754d1409bf5099314eea7e87e896622ade9bc0f;l=49>, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> whereas you've only specified 4 (fetch, navigation-failure, >>>>>>>>>>>>>>> parser-aborted, >>>>>>>>>>>>>>> websocket). Can you confirm that you're only shipping the >>>>>>>>>>>>>>> specified four? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Jul 13, 2023 at 12:11 AM Yoav Weiss < >>>>>>>>>>>>>>> yoav...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev < >>>>>>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> yu...@google.com, yu...@chromium.org, fer...@chromium.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/whatwg/html/pull/9360 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Design docs >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> NotRestoredReason API will report the list of reasons why >>>>>>>>>>>>>>>>> a page is not served from BFcache in a frame tree structure, >>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>> PerformanceNavigationTiming API. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> UI>Browser>Navigation>BFCache >>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/739 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Issues addressed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Gecko: Defer ( >>>>>>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/766) >>>>>>>>>>>>>>>>> Once issues (standardized reasons & unsalvageable documents), >>>>>>>>>>>>>>>>> they would >>>>>>>>>>>>>>>>> switch to positive. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems like the "standardized reasons" part is addressed >>>>>>>>>>>>>>>> in your PR. Is the same true for the second point? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> WebKit: No signal ( >>>>>>>>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/154) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Web developers: Positive ( >>>>>>>>>>>>>>>>> https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989 >>>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Other signals: Positive from Origin Trial users: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> How likely are you to keep using this feature? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 92% answered likely, 8% (1 vote) is unsure >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Security >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We do not report detailed information about cross-origin >>>>>>>>>>>>>>>>> iframes. See Security and Privacy section >>>>>>>>>>>>>>>>> <https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md#security-and-privacy> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> in the explainer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does this intent deprecate or change behavior of existing >>>>>>>>>>>>>>>>> APIs, such that it has potentially high risk for Android >>>>>>>>>>>>>>>>> WebView-based >>>>>>>>>>>>>>>>> applications? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In DevTools console, try: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> performance.getEntriesByType('navigation')[0].notRestoredReasons; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android >>>>>>>>>>>>>>>>> WebView)? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> NotRestoredReasons API is available on all platforms >>>>>>>>>>>>>>>>> including WebView, but back/forward cache is not enabled on >>>>>>>>>>>>>>>>> WebView. So on >>>>>>>>>>>>>>>>> WebView, NotRestoredReasons API should always say that the >>>>>>>>>>>>>>>>> page is blocked >>>>>>>>>>>>>>>>> from being restored from bfcache with the reason being >>>>>>>>>>>>>>>>> something like “not >>>>>>>>>>>>>>>>> supported”. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> (Currently it reports null due to a bug >>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1459533> >>>>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/performance-timeline/not-restored-reasons/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DevTrial instructions >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/rubberyuzu/bfcache-not-retored-reason/blob/main/HowToTest.md >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Flag nameblink RunTimeEnabledFeature: >>>>>>>>>>>>>>>>> BackForwardCacheSendNotRestoredReasons >>>>>>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=423?q=BackForwardCacheSendNotRestoredReasons%20-f:out&ss=chromium> >>>>>>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> False >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1326344 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://launch.corp.google.com/launch/4200848 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shipping on desktop >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial desktop last >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial desktop first >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DevTrial on desktop >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shipping on Android >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial Android last >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial Android first >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DevTrial on Android >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Shipping on WebView >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 116 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial WebView last >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 114 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> OriginTrial WebView first >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 109 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DevTrial on WebView >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 108 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Open questions about a feature may be a source of future >>>>>>>>>>>>>>>>> web compat or interop issues. Please list open issues. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/whatwg/html/pull/9360 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5684908759449600 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoGAzjUjzv3WmxcRpUSBgnA-AHQ05kh9gXc%2BQB8pRM6%2BfA%40mail.gmail.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHe391sAB2PdbEVw9uiSPFxTB_EYsRizcPpZ7-pg16O0A%40mail.gmail.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Intent to Extend Experiment: >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA5e698QcKZSthm%3Dz_4pi8cOzi4kfbx-AXveC%2BAKimUh-tMycA%40mail.gmail.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This intent message was generated by Chrome Platform >>>>>>>>>>>>>>>>> Status <https://chromestatus.com/>. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> 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+...@chromium.org. >>>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHYpT3sxWV%2BEipL5NcNSWy8fOdDdAroucmNb%3DZvxJWRBA%40mail.gmail.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-nMoHYpT3sxWV%2BEipL5NcNSWy8fOdDdAroucmNb%3DZvxJWRBA%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+...@chromium.org. >>>>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtkH6O82W%2BWm9ckCyYasSJt2cbs9VA4VZAmYhtivgj4g%40mail.gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXtkH6O82W%2BWm9ckCyYasSJt2cbs9VA4VZAmYhtivgj4g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "bfcache-dev" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to bfcache-dev...@chromium.org. >>>>>>>>>>> To view this discussion on the web, visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAM0wra-P3NxELP28%3Dgh%3D3ROC35m8ijS_5RRcStyjFew1AXNyEg%40mail.gmail.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAM0wra-P3NxELP28%3Dgh%3D3ROC35m8ijS_5RRcStyjFew1AXNyEg%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+...@chromium.org. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43e32f0e-454e-4525-b317-cbe492e2f23bn%40chromium.org >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/43e32f0e-454e-4525-b317-cbe492e2f23bn%40chromium.org?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/8172ecd3-8d20-4a04-9a95-18e25713e29an%40chromium.org.
