On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo <yu...@google.com> wrote:
> 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. > Note that "loading" is a nonstandard reason, so it would be bad to ship in that state. It should either be the correct reason ("parser-aborted") or the generi "masked" reason. > 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. > Similar to the above. > 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. > Allowing an implementation to always do "masked" and pass the tests seems reasonable to me. > > - 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? > You could ship the portion that is fully specified, but the portions in the draft PR would not be approved for shipment until they reach the usual bars (e.g., a fully reviewed spec, web platform tests, other-vendor positions, etc.). > > > 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/CAM0wra8Kr9r7UdfBkGeXRdWp3sEtusW8jO_Frnw-bwSwmaRu8Q%40mail.gmail.com.
