1611196 - When localStorage storage access checks fail, instead of throwing from the getter of window.localStorage, convert the object into a SessionStore equivalent object

Status: NEW

(Core :: Storage: localStorage & sessionStorage, enhancement, P3)

Description

[(no longer active)]

Right now when an access check for localStorage fails, we throw a SecurityError from window.localStorage. This matches the behaviour of Chromium. But WebKit has a different behaviour. Instead of disabling this object, it degrades localStorage to sessionStorage basically: it returns a DOMStorage object from window.localStorage that is double-keyed based on the origin of the top-level page, and its lifetime is bound to the browser session.

Doing this will have the benefit of fixing breakage issues caused by sites tripping over localStorage accesses which suddenly throw when storage access is denied in the third-party context.

Comment 1

[Anne (:annevk)]

Should we be doing the same for other storage APIs? (I.e., should this be a feature of QuotaManager somehow?) Also, we probably do not want to exactly match sessionStorage as I believe that's roughly per top-level browsing context?

Comment 2

[(no longer active)]

(In reply to Anne (:annevk) from comment #1)

Should we be doing the same for other storage APIs? (I.e., should this be a feature of QuotaManager somehow?)

It is hard to say. See bug 1607302.

Also, we probably do not want to exactly match sessionStorage as I believe that's roughly per top-level browsing context?

Right. I believe the slight distinction may have something to do with mitigating breakage but I'm not sure.

Comment 3

[(no longer active)]

Note that doing this will mean that once storage access is granted (e.g. through the storage access API) we will have two cookie jars that can be accessed via localStorage...

Comment 4

[Mike Conca [:mconca]]

We might be hitting this on the Chrome Platform Status website. When selecting an individual feature to report, the Adoption Chart (second chart on the page) never appears if ETP is enabled. Turning ETP off, it appears without issues. For example:

https://www.chromestatus.com/metrics/feature/timeline/popularity/2935

The console reports several errors similar to this one:

Request to access cookie or storage on “https://www.gstatic.com/charts/loader.js” was blocked because it came from a tracker and content blocking is enabled.