On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly <fer...@google.com> wrote:
> > > On Thu, 22 Feb 2024 at 16:32, Domenic Denicola <dome...@chromium.org> > wrote: > >> >> >> 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. >> > > "parser-aborted" is a reason that Chrome doesn't currently emit (it > doesn't exist in the code). I'm not sure how we ended up speccing a reason > that doesn't exist but I don't think we punt the entire NRR feature for > another milestone for that. > > > >> 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 think this one we can just make change http-status-no-ok to > navigation-failure. > > >> >> >>> 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 think this is a general issue with the testing. It should always be OK > for a UA to have extra reasons, e.g. when we do add parser-aborted, loading > will continue to show up. I guess we could add a hack to suppress loading > if parser-aborted is present but really what we care about in these tests > is that the specced reason is present in the specced case, > As we've discussed elsewhere on this thread, extra reasons are not OK; the APIs we ship need to be specified. "masked" is always OK though, per the spec. > > F > > > >> >> >>> >>> - 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/CAM0wra8KLFztjm06d7sQBUzKJFRW8QmGL0ueoq7v1oqiK1zFbQ%40mail.gmail.com.
