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+unsubscr...@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.

Reply via email to