Make storage api support history.pushState(). According to storage standard, history.pushState() is part of it. https://storage.spec.whatwg.org/

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.

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?

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.

(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.

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().

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.

(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?

> 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).

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.

(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

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

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?

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).

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.

or perhaps not domain but just url.

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

Pushed to Q1 2019