-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
Making the case for using traversal rather than reload as the navigation type for this scenario:
|
IIRC a 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! |
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? |
I know, it's counter-intuitive but the closest match.
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." |
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 |
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.
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. |
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.
Semantically for the word, sure.
Agreed. Having a |
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:
reload
instead ofback_forward
for "tab restore" w3c/navigation-timing#192navigation
API when observing history?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.
The text was updated successfully, but these errors were encountered: