Bugzilla

(In reply to Ksenia Berezina [:ksenia] from comment #1)
> I did a bit of investigation in https://github.com/webcompat/web-bugs/issues/109058#issuecomment-1244570448, and looks like the problem is that they put some data to the `sessionStorage` in the beginning of auth flow (while on  https://labs.openai.com/auth/login) to retrieve it later on, after sign in with google is performed. It redirects to https://auth0.openai.com/authorize?client_id=..., and later to https://auth0.openai.com/u/login/identifier?state=... where I click on "Continue with Google" and later redirected back to https://labs.openai.com/auth/callback?code=.. again , where it tries to retrieve that same `sessionStorage` data, but it turns out to be empty.

I assume that we have slightly differing implementation specific interpretations of what a session actually is and when it ends. Reading through [MDN sessionStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) one might understand that:

- a session's lifetime is bound to the document (which seems to be bound to the lifetime of the Window/tab and survives navigation inside the same window/tab)
- each origin (including sub-domains) has its own `sessionStore`

I'd interpret from this and a short peek on the spec, that we would expect the `sessionStorage` to survive the redirects as long as the Window/tab initially used remains open. While reasonable in this specific use case, it might be arguable if this is really what we always want, in particular if we are just navigating away without redirect and whilst the window/tab remained open much later and totally independently we click again on a link that brings us to the original origin - would we really want the `sessionStorage` to contain the old data?

In any case, apparently we have a third, implementation specific limitation, that is the lifetime of the content process that has been used when setting the storage item. It seems that once the process goes away (or is re-used for a different origin?) we lose our `sessionStorage`. IIUC, fission does "site-isolation", not origin (host-name) isolation, which would mean that during all the redirections we end up inside the same content process (which is never closed) and thus keep the `sessionStorage`. I **think** that in the non-fission case instead something makes us switch process while re-directing, resulting in a shiny new (and empty) `sessionStroage`.

We probably need to be more explicit in our implementation about the lifetime of `sessionStorage` to not be subject to such implicit side-effects.

Olli, am I getting this right and do you have more thoughts on the "session lifetime" we should align our implementation with?

(In reply to Ksenia Berezina [:ksenia] from comment #1)
> I did a bit of investigation in https://github.com/webcompat/web-bugs/issues/109058#issuecomment-1244570448, and looks like the problem is that they put some data to the `sessionStorage` in the beginning of auth flow (while on  https://labs.openai.com/auth/login) to retrieve it later on, after sign in with google is performed. It redirects to https://auth0.openai.com/authorize?client_id=..., and later to https://auth0.openai.com/u/login/identifier?state=... where I click on "Continue with Google" and later redirected back to https://labs.openai.com/auth/callback?code=.. again , where it tries to retrieve that same `sessionStorage` data, but it turns out to be empty.

I assume that we have slightly differing implementation specific interpretations of what a session actually is and when it ends. Reading through [MDN sessionStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) one might understand that:

- a session's lifetime is bound to the document (which seems to be bound to the lifetime of the Window/tab and survives navigation inside the same window/tab)
- each origin (including sub-domains) has its own `sessionStore`

I'd interpret from this and a short peek on the spec, that we would expect the `sessionStorage` to survive the redirects as long as the Window/tab initially used remains open. While reasonable in this specific use case, it might be arguable if this is really what we always want, in particular if we are just navigating away without redirect and whilst the window/tab remained open much later and totally independently we click again on a link that brings us to the original origin - would we really want the `sessionStorage` to contain the old data?

In any case, apparently we have a third, implementation specific limitation, that is the lifetime of the content process that has been used when setting the storage item. It seems that once the process goes away (or is re-used for a different origin?) we lose our `sessionStorage`. IIUC, fission does "site-isolation", not origin (host-name) isolation, which would mean that during all the redirections we end up inside the same content process (which is never closed) and thus keep the `sessionStorage`. I **think** that in the non-fission case instead something makes us switch process while re-directing, resulting in a shiny new (and empty) `sessionStorage`.

We probably need to be more explicit in our implementation about the lifetime of `sessionStorage` to not be subject to such implicit side-effects.

Olli, am I getting this right and do you have more thoughts on the "session lifetime" we should align our implementation with?