notRestoredReasons not updated when page enters bfcache

[tunetheweb]

As discussed here: https://github.com/WICG/bfcache-not-restored-reason/issues/2#issuecomment-2014605641

Consider this scenario:

• navigate to https://web.dev
• then www.example.com (which puts www.example.com into the bfcache)
• then hit back to return to https://web.dev. Go make a cup of tea and wait for a bit.
• Navigate forwards to https://www.example.com and you get a notRestoredReason of "timeout". So far so good.
• Now navigate to another site (e.g. developer.chrome.com). I would expect that to put www.example.com into the bfcache, but when I go back I still have a notRestoredReason of "timeout".
• However it WAS put into bfcache, it's just the notRestoredReasons was not updated because of that.

Apparently this is expected:

This is an expected behavior. NotRestoredReasons are only built when unloading a document - e.g. only for non-bfcache history navigation. (spec) So if the next navigation is restored from bfcache, NotRestoredReasons are never updated, and the reasons are supposed to stay.

We have a wpt for this too. 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

But this seems really confusing to me. We have a page that was restored from the bfcache but also a reason why it could not be put in the bfcache.

Shouldn't the notRestoredReasons be zero-ed out when a page is put into the bfcache?

[rubberyuzu]

I can see this can be confusing to developers. @domenic Can we add a logic to reset NRR when the page enters bfcache, both to the spec and to the implementation?

[domenic]

Yes, that seems fine to me.