This wouldn't actually work for sites like facebook because when it reloads it actually loads different content.

But for more static content it would. We definitely should restore scroll position. Don't we already do so today? 

Note: We currently restore by pixel offset. We should at some point change it to use the new scroll anchoring logic that is by DOM offsets.

Do we have a component or label for tab discard tasks?

This is not specific to tab discarding right? the case described here is: navigate away and then navigate back.

re:c5, The specific case we're filing for is during a discard. It is fine to navigate away to gmail for a second and come back and see facebook where you left it. But the problem occurs when one navigates to check an email, or change a song, etc etc., comes back 10 seconds later and the tab is discarded, and the user has to start all over again. The user expects a continuous workflow.

I'm not sure if this is a problem without a discard. But sarahgordon@ (cc'ed) experienced this a lot.

I think we're using the word "navigate" differently here. Typically we use navigate for clicking on a link and having the current tab go to a new URL and would call what you're describing as focusing a different tab.

Again, we currently have logic that restores scroll position on crashes. I'd be surprised if that wasn't running for tab discarding, but it's possible. But there's some dynamic pages it won't work for (facebook, twitter, etc.).

Chris, can you confirm that on a page like wikipedia that we do actually restore scroll position when restoring a discarded tab?

I think there is room to improve the logic using scroll anchoring though. The current logic doesn't know *when* to restore scroll. With scroll anchoring we can repeatedly do it during page load until we find the right element to scroll to.

 Issue 734679  tracks restoration with scroll anchoring.  That won't do anything for dynamic infinite scrollers though.

BTW I confirmed that on wikipedia we do infact restore scroll position when a discarded tab is revisited.

re:c7, good point. Yes navigation in my comment was just switching tabs, not clicking a new site in the tab. I will adjust my language.

And yes, i also confirmed, wikipedia will return to the correct spot after discard.

I can't think of anything we can do about the facebook/twitter style pages since it's totally different content on reload other than give them an opt-out so they get discarded last. The opt-out has it's own problem of being rife for abuse though.

I do think that the scroll anchoring approach ( issue 734679 ) would help content that is dynamically generated, but the same on every page load though by removing common races (e.g. nytimes).

The plan here is to enable the app to restore itself:
1. run unload on the path to discard: this is to enable the app to save transient view state (session storage), so they are track where user is in FB / twitter
 (Does unload run today in "safe" discard case?)

2. when user revisits provide a signal in the subsequent pageshow event: "previousState", an enum which will return "discarded" in this case
The app can use this signal to restore itself.

However as Ojan said, there isn't a short term solution here.

I don't know what category tab discarding is internally, but it's not browser UI.

Maybe the Blink Memory folks know.