what should navigation_type be after a session restore?

[Fergal Daly]

I just tried

performance.getEntriesByType('navigation')[0].type

after going back and then forward and then quit and restart chrome and the result is

'back_forward'

Is this WAI? I was kind-of expecting it to be 'reload'. I can see arguments for both but if we stick with 'back_forward' then I think it's impossible to correctly measure the BFCache hit-rate in JS - every session restore will look like a cache-miss when it was never eligible for BFCache.

FF does the same thing. I don't have safari to test.

Is there something else that gives a reliable signal that the page was loaded after a session restore? It will be visible in the up-coming not-restored-reasons API. Just wondering if there's something else that exists currently. Setting a session cookie would do it but I'm looking for something more like the performance API,

F

[Domenic Denicola]

In general I think session restore is an area that could benefit from more spec attention. (E.g., it's not really specified that history.state should be restored by session restore, but many sites depend on it.) I think focusing on the needs of authors and measurement in this way is a great starting place.

I can't think of anything that gives you the information passively. All I can think of depends on storing information and then seeing its status (e.g. history.state, sessionStorage, session cookies).

Adding a new dedicated API might be a good path here. +Noam Rosenthal +Yoav Weiss probably have the most insight into where that would fit, in the performance API space.

[Yoav Weiss]

On Mon, May 16, 2022 at 8:02 PM Domenic Denicola <dom...@chromium.org> wrote:

In general I think session restore is an area that could benefit from more spec attention. (E.g., it's not really specified that history.state should be restored by session restore, but many sites depend on it.) I think focusing on the needs of authors and measurement in this way is a great starting place.

I can't think of anything that gives you the information passively. All I can think of depends on storing information and then seeing its status (e.g. history.state, sessionStorage, session cookies).

Adding a new dedicated API might be a good path here. +Noam Rosenthal +Yoav Weiss probably have the most insight into where that would fit, in the performance API space.

On Thu, May 12, 2022 at 6:12 PM Fergal Daly <fer...@google.com> wrote:

I just tried

performance.getEntriesByType('navigation')[0].type

after going back and then forward and then quit and restart chrome and the result is

'back_forward'

Is this WAI? I was kind-of expecting it to be 'reload'.

The spec defines "back_forward" as a navigation where the history handling behavior is "entry update", so "a navigation to an existing session history entry".

So it sounds like WAI for a navigation after a session restore, as specified. It may make sense to expose it as a separate navigation type though.

Would it make sense to define a new history handling behavior that signifies that the page was loaded after a session restore?

If so, it'd be easy to hang a separate navigation type on top of that. 

But maybe the first step is to file an issue on Navigation Timing and see if people would be interested in the data.

[Noam Rosenthal]

I think NotRestoredReason is the right place for this information.

It seems clean to me that session-restore is aligned with regular non-cached history traversal as much as possible, which makes the fact that it's under-specified less painful.

In that sense, I believe back_forward is a good enough navigation_type for session restore (in a way, you are going "back" to that page as in returning to it), and NotRestoredReason can perhaps divulge that this is a session-restore, though we should see if that's OK privacy-wise.

[Fergal Daly]

I just filed

https://github.com/w3c/navigation-timing/issues/179

1 comment below.

On Tue, 17 May 2022 at 16:21, Noam Rosenthal <noam.j.r...@gmail.com> wrote:

I think NotRestoredReason is the right place for this information.

It seems clean to me that session-restore is aligned with regular non-cached history traversal as much as possible, which makes the fact that it's under-specified less painful.

In that sense, I believe back_forward is a good enough navigation_type for session restore (in a way, you are going "back" to that page as in returning to it), and NotRestoredReason can perhaps divulge that this is a session-restore, though we should see if that's OK privacy-wise.

Whether this is a good or a bad thing, I don't know but exposing it as a NotRestoredReason would provide less information unless we had a specific reason for session-restore/clone. E.g. if the user gets to a.com via `navigate` and then clones then we could have a NotRestoresReason of `ineligible` but there's no way to know there was a session restore because the `navigate` made it ineligible. Is this a bug or a feature?

[Noam Rosenthal]

On Tue, 17 May 2022 at 9:53 Fergal Daly <fer...@google.com> wrote:

I just filed

https://github.com/w3c/navigation-timing/issues/179

1 comment below.

On Tue, 17 May 2022 at 16:21, Noam Rosenthal <noam.j.r...@gmail.com> wrote:

I think NotRestoredReason is the right place for this information.

It seems clean to me that session-restore is aligned with regular non-cached history traversal as much as possible, which makes the fact that it's under-specified less painful.

In that sense, I believe back_forward is a good enough navigation_type for session restore (in a way, you are going "back" to that page as in returning to it), and NotRestoredReason can perhaps divulge that this is a session-restore, though we should see if that's OK privacy-wise.

Whether this is a good or a bad thing, I don't know but exposing it as a NotRestoredReason would provide less information unless we had a specific reason for session-restore/clone. E.g. if the user gets to a.com via `navigate` and then clones then we could have a NotRestoresReason of `ineligible` but there's no way to know there was a session restore because the `navigate` made it ineligible. Is this a bug or a feature?

the fact that session-restore is not currently web observable (as far as I can tell) is a feature, but it doesnt mean it has to stay that way ☺️ 

[Domenic Denicola]

Check out https://groups.google.com/a/chromium.org/g/blink-dev/c/o0F7nBKsgg0/m/bJSp3ekfAAAJ , wherein Microsoft is proposing a new "useragent_launch" value for the type field that seems to have substantial overlap with this question. I think the bfcache team should engage with them and see if we can either use their proposal, or build on it.

[Fergal Daly]

On Fri, 20 May 2022 at 07:16, Domenic Denicola <dom...@chromium.org> wrote:

Check out https://groups.google.com/a/chromium.org/g/blink-dev/c/o0F7nBKsgg0/m/bJSp3ekfAAAJ , wherein Microsoft is proposing a new "useragent_launch" value for the type field that seems to have substantial overlap with this question. I think the bfcache team should engage with them and see if we can either use their proposal, or build on it.

Thanks. I left a comment.

I started off thinking there was overlap but  maybe there's not. Anyway, good to align,