Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

Now that M123 implementation is aligned with the spec 
, can we ship the feature to M123?

We're currently working on adding browser-specific blocking reasons (i.e. 
reasons that may block) to the spec in this PR 
, and while this is still under 
review and the details of the names can change, the overall direction will 
stay the same. Firefox folks are also engaged with speccing the names on 
the PR.

Please let me know what you think, thanks!
Yuzu


On Thursday, February 22, 2024 at 8:30:24 PM UTC+9 Fergal Daly wrote:

> On Thu, 22 Feb 2024 at 18:03, Domenic Denicola  
> wrote:
>
>>
>>
>> On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly  wrote:
>>
>>>
>>>
>>> On Thu, 22 Feb 2024 at 16:32, Domenic Denicola  
>>> wrote:
>>>


 On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo  wrote:

> Thanks Domenic for bringing up the concerns!
>
>- I found 
>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 
>
> ,
>  
>which seem to match up with the failures on wpt.fyi 
>
> .
>  
>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 
> ),
>  
> 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.
>>
>
> Any restore can be blocked for multiple reasons. That can be for a mix of 
> common and UA-specific reasons (all of which appear in the spec). As long 
> as the common reason appears in the test for the common reason, the test 
> should pass. Otherwise are writing tests that assert that UA-specific 
> reasons are absent in some cases. I don't think we should be doing that. 
> UAs can block on UA-specific reasons whenever they want and be within spec,
>
> F 
>
>  
>
>>  
>>
>>>
>>> F
>>>
>>>  
>>>
  

>
>- I found a nonstandard 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Fergal Daly' via blink-dev]

On Thu, 22 Feb 2024 at 18:03, Domenic Denicola  wrote:

>
>
> On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly  wrote:
>
>>
>>
>> On Thu, 22 Feb 2024 at 16:32, Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo  wrote:
>>>
 Thanks Domenic for bringing up the concerns!

- I found
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

 ,
which seem to match up with the failures on wpt.fyi

 .
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
 ),
 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.
>

Any restore can be blocked for multiple reasons. That can be for a mix of
common and UA-specific reasons (all of which appear in the spec). As long
as the common reason appears in the test for the common reason, the test
should pass. Otherwise are writing tests that assert that UA-specific
reasons are absent in some cases. I don't think we should be doing that.
UAs can block on UA-specific reasons whenever they want and be within spec,

F



>
>
>>
>> F
>>
>>
>>
>>>
>>>

- I found a nonstandard toJSON() in NotRestoredReasonDetails

 
  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 
 (have't added the explanation for each reason yet).
 Is it okay to ship while we 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly  wrote:

>
>
> On Thu, 22 Feb 2024 at 16:32, Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo  wrote:
>>
>>> Thanks Domenic for bringing up the concerns!
>>>
>>>- I found
>>>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
>>>
>>> ,
>>>which seem to match up with the failures on wpt.fyi
>>>
>>> .
>>>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
>>> ),
>>> 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
>>>
>>> 
>>>  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 
>>> (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  wrote:

> On Wed, 7 Feb 2024 at 12:26, Domenic Denicola 
> wrote:
>
>>
>>
>> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:
>>
>>> On Tue, 6 Feb 2024 at 15:13, 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Fergal Daly' via blink-dev]

On Thu, 22 Feb 2024 at 16:32, Domenic Denicola  wrote:

>
>
> On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo  wrote:
>
>> Thanks Domenic for bringing up the concerns!
>>
>>- I found
>>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
>>
>> ,
>>which seem to match up with the failures on wpt.fyi
>>
>> .
>>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
>> ),
>> 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,

F



>
>
>>
>>- I found a nonstandard toJSON() in NotRestoredReasonDetails
>>
>> 
>>  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 
>> (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  wrote:
>>>
 On Wed, 7 Feb 2024 at 12:26, Domenic Denicola 
 wrote:

>
>
> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:
>
>> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola 
>> 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
>>>
>>> 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

On Thu, Feb 22, 2024 at 4:20 PM Yuzu Saijo  wrote:

> Thanks Domenic for bringing up the concerns!
>
>- I found
>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
>
> ,
>which seem to match up with the failures on wpt.fyi
>
> .
>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
> ),
> 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
>
> 
>  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 
> (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  wrote:
>>
>>> On Wed, 7 Feb 2024 at 12:26, Domenic Denicola 
>>> wrote:
>>>


 On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:

> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola 
> 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
>>
>> 
>>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
>>
>> ,
>>which seem to match up with the failures on wpt.fyi
>>
>> 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

Thanks Domenic for bringing up the concerns!

   - I found 
   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 
   
,
 
   which seem to match up with the failures on wpt.fyi 
   
.
 
   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 
),
 
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 
   

 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  
(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  wrote:
>
>> On Wed, 7 Feb 2024 at 12:26, Domenic Denicola  
>> wrote:
>>
>>>
>>>
>>> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:
>>>
 On Tue, 6 Feb 2024 at 15:13, Domenic Denicola  
 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 
>
> 
>  
>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 
>
> ,
>  
>which seem to match up with the failures on wpt.fyi 
>
> .
>  
>Will those be addressed before shipping?
>- I found a nonstandard toJSON() in NotRestoredReasonDetails 
>
> 
>  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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

On Wed, Feb 7, 2024 at 12:51 PM Fergal Daly  wrote:

> On Wed, 7 Feb 2024 at 12:26, Domenic Denicola 
> wrote:
>
>>
>>
>> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:
>>
>>> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola 
>>> 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

 
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

 ,
which seem to match up with the failures on wpt.fyi

 .
Will those be addressed before shipping?
- I found a nonstandard toJSON() in NotRestoredReasonDetails

 
  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
>> )
>> 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
, and then
document that some of them may be thrown in implementation-specific
circumstances (example ).


>
> 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  wrote:

> This is now ready to ship, now that we have all the approvals on the
> ChromeStatus
> and
> the spec draft  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
>> 
>> .
>>
>> 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
>>> 
>>> for the "may block" reasons 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Fergal Daly' via blink-dev]

On Wed, 7 Feb 2024 at 12:26, Domenic Denicola  wrote:

>
>
> On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:
>
>> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola 
>> 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
>>>
>>> 
>>>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
>>>
>>> ,
>>>which seem to match up with the failures on wpt.fyi
>>>
>>> .
>>>Will those be addressed before shipping?
>>>- I found a nonstandard toJSON() in NotRestoredReasonDetails
>>>
>>> 
>>>  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
> )
> 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.

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,

F


>
>
>>
>> F
>>
>>
>>
>>>
>>>
>>>
>>> On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo  wrote:
>>>
 This is now ready to ship, now that we have all the approvals on the
 ChromeStatus
 and
 the spec draft  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
> 
> .
>
> 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
>> 
>> for the "may block" reasons then.
>>
>> Re: exposing NotRestoredReasons interface instead of object in idl:
>> I'm working on the implementation in this CL
>> .
>> 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 
>>> wrote:
>>>
 On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
 wrote:

> I think specifying these reasons is important. As noted in the
> linked issue
> 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly  wrote:

> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola 
> 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
>>
>> 
>>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
>>
>> ,
>>which seem to match up with the failures on wpt.fyi
>>
>> .
>>Will those be addressed before shipping?
>>- I found a nonstandard toJSON() in NotRestoredReasonDetails
>>
>> 
>>  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
)
then that needs to be specified in the spec PR before shipping such a value
in Chromium.


>
> F
>
>
>
>>
>>
>>
>> On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo  wrote:
>>
>>> This is now ready to ship, now that we have all the approvals on the
>>> ChromeStatus
>>> and
>>> the spec draft  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
 
 .

 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
> 
> for the "may block" reasons then.
>
> Re: exposing NotRestoredReasons interface instead of object in idl:
> I'm working on the implementation in this CL
> .
> 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  wrote:
>>
>>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
>>> wrote:
>>>
 I think specifying these reasons is important. As noted in the
 linked issue
 , 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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Fergal Daly' via blink-dev]

On Tue, 6 Feb 2024 at 15:13, Domenic Denicola  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
>
> 
>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
>
> ,
>which seem to match up with the failures on wpt.fyi
>
> .
>Will those be addressed before shipping?
>- I found a nonstandard toJSON() in NotRestoredReasonDetails
>
> 
>  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?

F



>
>
>
> On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo  wrote:
>
>> This is now ready to ship, now that we have all the approvals on the
>> ChromeStatus
>> and
>> the spec draft  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
>>> 
>>> .
>>>
>>> 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
 
 for the "may block" reasons then.

 Re: exposing NotRestoredReasons interface instead of object in idl:
 I'm working on the implementation in this CL
 .
 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  wrote:
>
>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
>> wrote:
>>
>>> I think specifying these reasons is important. As noted in the
>>> linked issue
>>> , 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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

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
   

   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
   
,
   which seem to match up with the failures on wpt.fyi
   
.
   Will those be addressed before shipping?
   - I found a nonstandard toJSON() in NotRestoredReasonDetails
   

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"?




On Mon, Feb 5, 2024 at 5:38 PM Yuzu Saijo  wrote:

> This is now ready to ship, now that we have all the approvals on the
> ChromeStatus
> and
> the spec draft  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
>> 
>> .
>>
>> 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
>>> 
>>> for the "may block" reasons then.
>>>
>>> Re: exposing NotRestoredReasons interface instead of object in idl:
>>> I'm working on the implementation in this CL
>>> .
>>> 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  wrote:

> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
> wrote:
>
>> I think specifying these reasons is important. As noted in the
>> linked issue
>> , 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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

This is now ready to ship, now that we have all the approvals on the 
ChromeStatus  
and 
the spec draft  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 
> 
> .
>
> 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 
>> 
>>  
>> for the "may block" reasons then.
>>
>> Re: exposing NotRestoredReasons interface instead of object in idl:
>> I'm working on the implementation in this CL 
>> .
>> 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  wrote:
>>>
 On Wed, 9 Aug 2023 at 12:01, Domenic Denicola  
 wrote:

> I think specifying these reasons is important. As noted in the linked 
> issue , 
> 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  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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Chris Harrelson]

Please also make sure to complete all of the other shipping gate reviews

.

Thanks!
Chris

On Thu, Aug 10, 2023 at 8:46 AM 'Yuzu Saijo' via blink-dev <
blink-dev@chromium.org> wrote:

> Sounds good, I will create a list on the explainer
> 
> for the "may block" reasons then.
>
> Re: exposing NotRestoredReasons interface instead of object in idl:
> I'm working on the implementation in this CL
> .
> 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  wrote:
>>
>>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
>>> wrote:
>>>
 I think specifying these reasons is important. As noted in the linked
 issue ,
 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  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

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

Sounds good, I will create a list on the explainer 

 
for the "may block" reasons then.

Re: exposing NotRestoredReasons interface instead of object in idl:
I'm working on the implementation in this CL 
.
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  wrote:
>
>> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola  
>> wrote:
>>
>>> I think specifying these reasons is important. As noted in the linked 
>>> issue , 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  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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

On Wed, Aug 9, 2023 at 6:44 PM Fergal Daly  wrote:

> On Wed, 9 Aug 2023 at 12:01, Domenic Denicola 
> wrote:
>
>> I think specifying these reasons is important. As noted in the linked
>> issue , 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  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
 .
 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
> 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Fergal Daly' via blink-dev]

On Wed, 9 Aug 2023 at 12:01, Domenic Denicola  wrote:

> I think specifying these reasons is important. As noted in the linked
> issue , 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),

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  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
>>> .
>>> 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
 
  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 
 wrote:

> I have some questions about how well the implementation here matches
> up with the spec.
>
> First, 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

I think specifying these reasons is important. As noted in the linked issue
, 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.)
   - 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.

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  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
>> .
>> 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
>>> 
>>>  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 
>>> 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?
 .
 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
 ,
 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 
 wrote:

>
>
> On Thu, Jul 6, 2023 at 7:28 AM 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

+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 
> .
> 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 
>> 
>>  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  
>> 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? 
>>> .
>>>  
>>> 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 
>>> ,
>>>  
>>> 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  
>>> 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 
> 
>
> 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?
  

>

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

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 
.
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 
> 
>  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  
> 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? 
>> .
>>  
>> 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 
>> ,
>>  
>> 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  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 
 

 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 
 
  
 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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

Also, checking the tests, it seems like the currently-implemented reasons
don't match the spec. E.g. this test

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 
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?
> .
> 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
> ,
> 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 
> wrote:
>
>>
>>
>> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
>> blink-dev@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
>>> 
>>>
>>> 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
>>> 
>>> 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
>>> )
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> 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:
>>> 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Domenic Denicola]

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?
.
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
,
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  wrote:

>
>
> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
> blink-dev@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
>> 
>>
>> 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
>> 
>> 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
>> )
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> 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
>> 
>> 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 

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

[Yoav Weiss]

On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
blink-dev@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
> 
>
> 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
> 
> 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
> )
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> 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
> 
> 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
> .
>
> --
> You received this message because you are subscribed to the Google