Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Description • 7 years ago

Make storage api support history.pushState().
According to storage standard, history.pushState() is part of it. 

https://storage.spec.whatwg.org/

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 1 • 7 years ago

It seems to me that supporting history.pushState() requires to change session restore data location from "$PROFILE/sessionstore-backups/recovery.jsonlz4" to storage folder per origin. However, that's not origin based metadata. All the information is aggregated together with the same json file. Unlike cache and idb, we probably need to think about how to manage this from QM.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 2 • 7 years ago

I wondered that how we can achieve it since history.pushState() is related to browsing context and it is not related to site data. That doesn't apply origin based concept. Anne, could you please explain the reason the specification includes history.pushState() in site data?

	Anne (:annevk)
	Comment 3 • 7 years ago

The main reason I labeled it as such is that it's data that shouldn't leak across origins and should be cleared along with Indexed DB and such. I guess there is some argument to be made for tying it to history though.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 4 • 7 years ago

(In reply to Anne (:annevk) from comment #3)
> The main reason I labeled it as such is that it's data that shouldn't leak
> across origins and should be cleared along with Indexed DB and such. I guess
> there is some argument to be made for tying it to history though.
Do you mind giving an example what you expect? I'm still not sure about the behavior. Since the current implementation ties to history. history.pushState only manipulates history stack. If that tab is closed, then we also need to modify session restore data.

	Anne (:annevk)
	Comment 5 • 7 years ago

Say I navigate around example.com and example.com makes use of pushState() while I do so. I then clear storage for example.com or more generally. If I then press back or some such I would expect example.com to not have access to any state stored with pushState().

	Jan Varga [:janv]
	Comment 6 • 7 years ago

I don't know about history.pushState() much. The first thing that should be investigated is if it can store its data per origin. Or if it even makes sense something like that for pusthState().
Quota Manager currently heavily depends on per origin design.
As I said I don't know about session store much, but storing everything in one file can be a performance problem. Would it help if it was stored in separate per origin files ?
For example, if something changed and we need to persist it to disk, would it help if we persisted data only for specific origin ?
I remember that they had to add compression because of performance problems.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 7 • 7 years ago

(In reply to Anne (:annevk) from comment #5)
> Say I navigate around example.com and example.com makes use of pushState()
> while I do so. I then clear storage for example.com or more generally. If I
> then press back or some such I would expect example.com to not have access
> to any state stored with pushState().

That seems like a very big change since we only have one session restore single file.
Based on the experience of LocalStorage database and ServiceWorker registration file, we need to storage pushState under storage folder per origin. That also affects session restore function.

Olli, do you have any suggestion or concern about splitting pushState data per origin and managed by QuotaManager?

	Jan Varga [:janv]
	Comment 8 • 7 years ago

> That seems like a very big change since we only have one session restore single file.
Of course it's a big change, so we must be sure it's a good thing to do from all perspectives.

I quickly scanned browser/components/sessionstore and it seems it does use principal/origin based structures/methods.

It also seems that entire session restore file is read at startup, in theory data could be read on demand when it's actually needed (as far as I know tabs are initialized lazily).

	Anne (:annevk)
	Comment 9 • 7 years ago

I suspect we might not want to combine it, but make sure that we have a higher-level deletion operation that takes both (and probably more) into account. We also need to clarify the specification in that case.

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 10 • 7 years ago

(In reply to Anne (:annevk) from comment #9)
> account. We also need to clarify the specification in that case.
https://github.com/whatwg/storage/issues/50

	Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor) Reporter
	Comment 11 • 7 years ago

If tab is closed, do we still delete persisted data?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 12 • 7 years ago

Comment 5 is rather surprising. If we clear the data, we need to also modify the session history, or otherwise the history doesn't really make sense.
Anne, is the plan to somehow map storage clearance to session history too?

	Anne (:annevk)
	Comment 13 • 7 years ago

Olli, I think users expect those to be cleared together, to the extent possible. (I don't think that necessarily means we need to put their stores together in the backend though, as I said in comment 9.)

https://w3c.github.io/webappsec-clear-site-data/ also ends up clearing both (though has controls to separate them).

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 14 • 7 years ago

Ok, so it is not just the state but about those session history entries which include some state.
I wonder which all then... Perhaps only the first entry for the top level page from the particular domain should stay in the session history and everything else would be removed.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 15 • 7 years ago

or perhaps not domain but just url.

	Andrew Sutherland [:asuth] (he/him)
	Comment 16 • 7 years ago

Note that we have at least some tests about this:
https://searchfox.org/mozilla-central/source/browser/base/content/test/general/browser_purgehistory_clears_sh.js

	Marion Daly [:mdaly]
	Comment 17 • 6 years ago

Pushed to Q1 2019