Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tab-restore is somewhat observable but not specified #9941

Open
noamr opened this issue Nov 20, 2023 · 9 comments
Open

Tab-restore is somewhat observable but not specified #9941

noamr opened this issue Nov 20, 2023 · 9 comments

Comments

@noamr
Copy link
Contributor

noamr commented Nov 20, 2023

What is the issue with the HTML Standard?

"Tab restore" is when the browser restarts and automatically loads tabs that were open before it was closed.
UAs implement this somewhat differently, yet this is observable in a few places:

The main thing that's in question is the "navigation type" in that situation.
Note that it can't be navigate, because the browser might restore the forward history.
In the navigation API this is currently exposed as back_forward (a traverse), but perhaps it's actually a reload?

Specifying what this tab restore actually is would help us decide how it is exposed as a navigation type or otherwise.

@noamr
Copy link
Contributor Author

noamr commented Nov 23, 2023

Making the case for using traversal rather than reload as the navigation type for this scenario:

  1. Conceptually, what's happening here is a restore from history. Perhaps "back_forward" or "traversal" is a poor name for it, but the essence is the same: we load the history, and then traverse to a particular session in it.
  2. If BFCache supports persistence to disk in some implementation as some point, this could be utilized here: a session restore doesn't only restore the history, but even restores it entire JS state etc.
  3. I could be missing a scenario, but as a general rule a reload has an active document when it's invoked. This is observable - if you put the timing of your pagehide into sessionStorage, you should observe if it was there upon reload. So if you don't see a pagehide that coincide with the start time of this reload, this is very likely a tab restore. The same is not true for marking it as traversal, you could be going to a page that had been in history and was evicted (this is essentially what happened anyway...)

@tunetheweb
Copy link
Contributor

IIRC a reload always goes back to a server to check freshness even if within cache time doesn't it? While back_forward doesn't and neither does a restore. So yeah, it acts more like a back_forward navigation, even if I do think that type is somewhat unintuitive for a restore.

BTW "tab restore" can also happen without a browser restart (e.g. if a tab is discarded due to memory but still appears as a tab and is restored on activating that tab or using Right Click -> Reopen Close Tab on Chrome/Firefox). But don't think that changes anything about what we're saying here so just noting it for the record!

@domenic
Copy link
Member

domenic commented Nov 23, 2023

Fundamentally I think it's very weird if you're traversing, but there's nowhere "from" you're traversing, and you didn't change your history entry.

Can we introduce a new type?

@noamr
Copy link
Contributor Author

noamr commented Nov 23, 2023

Fundamentally I think it's very weird if you're traversing, but there's nowhere "from" you're traversing, and you didn't change your history entry.

I know, it's counter-intuitive but the closest match.

Can we introduce a new type?

That would make tab-restore web-exposed. Are we ok with that?

@domenic
Copy link
Member

domenic commented Nov 23, 2023

That would make tab-restore web-exposed. Are we ok with that?

We're already proposing to make it web-exposed, by exposing it as a traversal but then having it not meet many other aspects of a traversal. The author can tell that these differences exist from other traversals.

@noamr
Copy link
Contributor Author

noamr commented Nov 23, 2023

That would make tab-restore web-exposed. Are we ok with that?

We're already proposing to make it web-exposed, by exposing it as a traversal but then having it not meet many other aspects of a traversal. The author can tell that these differences exist from other traversals.

How is that observable? You could be traversing from a cross-origin entry you don't know about. That would look like you're "traversing from nowhere".

I don't understand "you didn't change your history entry."

@noamr
Copy link
Contributor Author

noamr commented Nov 23, 2023

Also conceptually, why does traversing the history has to come "from" somewhere? perhaps you opened a UI screen containing your history and traversed it from there, wouldn't that be considered traversing the history? I

@domenic
Copy link
Member

domenic commented Nov 30, 2023

How is that observable? You could be traversing from a cross-origin entry you don't know about. That would look like you're "traversing from nowhere".

I think you're right, although I'm often surprised by the observability of these things. I suspect there are tricks based on, e.g., sessionStorage, session cookies, cache lifetimes, etc.

Also conceptually, why does traversing the history has to come "from" somewhere?

Because that's kind of the definition of the word? To go from one place to another? And in the context of web browsing, it means to go from one (existing) history entry to another (existing) history entry?


Overall I'd like some clarity on whether it's a privacy requirement to not expose the existence of session restores. If so, we need to pick the least-bad existing option to represent them. But if not, then I feel that they deserve their own type.

@noamr
Copy link
Contributor Author

noamr commented Nov 30, 2023

How is that observable? You could be traversing from a cross-origin entry you don't know about. That would look like you're "traversing from nowhere".

I think you're right, although I'm often surprised by the observability of these things. I suspect there are tricks based on, e.g., sessionStorage, session cookies, cache lifetimes, etc.

It's possible but I'm not sure how difficult they are as a way to differentiate between a cross-origin traversal and a tab restore.

Also conceptually, why does traversing the history has to come "from" somewhere?

Because that's kind of the definition of the word? To go from one place to another? And in the context of web browsing, it means to go from one (existing) history entry to another (existing) history entry?

Semantically for the word, sure.
One could think about this as a history that also includes "the tab/browser is closed" as a point in time and you're traversing from there. But I concede that it's a stretch.

Overall I'd like some clarity on whether it's a privacy requirement to not expose the existence of session restores. If so, we need to pick the least-bad existing option to represent them. But if not, then I feel that they deserve their own type.

Agreed. Having a restore navigation type would be the best for developers if we can justify it in terms of privacy.
I'll ask around internally and would be happy for feedback from @annevk and @smaug----.
My point in this thread is to show that if we need to somehow camouflage tab-restores, pretending to be a cross-origin history traversal is the closest choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants