Thank you for bringing up that use case, Ryan. I should have mentioned that I'll file bugs for all internal users of storage: "persistent" so that we can deal with this in the 61 cycle. As Andrew mentioned we don't expect any issues, and it's a priority that this change is not an inconvenience or causes disruption to any other team.
Thanks! Johann Andrew Sutherland wrote: > QuotaManager already has a notion of "internal" origins[1] that explicitly > white-lists devtools' synthetic "indexeddb" fake scheme. It's this check > that avoids the prompt when persistent storage is requested. > > It might make sense to expand the existing logic that acts like all > system-principaled origins are asking for persistent storage[2] to use the > check as well, or at least for the IndexedDB protocol until we get to the > next steps for changing how QuotaManager handles persistent data. We could > do this in the same commit that removes devtools' use of the storage property. > > Andrew > > 1: > https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/quota/ActorsParent.cpp#5524 > > 2: > https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/dom/indexedDB/IDBFactory.cpp#681 > > > On 03/06/2018 01:18 PM, J. Ryan Stinnett wrote: >> DevTools is one chrome caller that might be impacted. We craft a custom >> principal and pass `storage: persistent`[1] when using IndexedDB in the >> tools. >> >> DevTools uses this storage for developer settings that should be retained >> over time. It sounds like with the proposed change here, DevTools storage >> might lose the persistent status. If that's true, what's the right approach >> to maintain the status quo? I don't think it makes sense to show a >> permission prompt when DevTools access its storage, since it is a browser >> feature. >> >> Should we add an exception for the DevTools iDB principal? Should DevTools >> use the system principal and migrate existing data? >> >> [1]: >> https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/devtools/shared/indexed-db.js#34 >> >> - Ryan >> >> On Tue, Mar 6, 2018 at 9:58 AM, Johann Hofmann <jhofm...@mozilla.com> wrote: >> >>> I would like to unship the proprietary "storage" attribute in >>> indexedDB.open()[0]. It allows developers to prevent their indexedDB >>> storage from being evicted as part of quota management[1]. However, >>> there is a web standard which specifies a better persistent storage >>> mechanism and has broader vendor support[2]. >>> >>> There are several issues with the old proprietary version: >>> >>> - It's only supported by Firefox. >>> - It can be used over insecure HTTP, which is against the persistent >>> storage spec. >>> - Its internal mechanism is only concerned with indexedDB and does not >>> integrate with other quota managed storage. >>> - We actually need to maintain two separate permissions that do more or >>> less the same thing ("indexedDB" and "persistent-storage"). The UI for >>> managing these looks almost exactly the same and it's impossible to >>> clarify the difference. It's a pretty annoying security/privacy UX issue >>> and difficult to justify to users. >>> >>> The plan is to ignore the "storage" attribute and label all databases >>> opened from iDB.open as default (i.e. dependent on the persistent >>> storage mechanism). >>> >>> Before doing this, we will issue a deprecation warning in the browser >>> console and write a blog post on Mozilla Hacks. Affected websites could >>> lose their indexedDB data (equivalent to the user clearing their >>> cookies), unless they migrate to the new storage model. >>> >>> We are tracking this work in bug 1354500 >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1354500). >>> >>> We have seen very low usage on beta[3], with the exception of a spike in >>> November which we attribute to about:home usage from a/b testing. After >>> we stopped counting usage from about: pages on Nightly, the telemetry >>> probe stopped signaling completely[4]. >>> >>> I personally consider these numbers (prior to any evangelism or console >>> warnings) low enough to unship within the Firefox 62 timeframe, without >>> migration. >>> >>> Chrome callers should not be affected by this, since we upgrade the >>> system principal to persistent storage automatically. >>> >>> Please let me know what you think. >>> >>> Thanks, >>> >>> Johann >>> >>> [0] https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/ >>> open#Syntax >>> [1] >>> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_ >>> API/Browser_storage_limits_and_eviction_criteria >>> [2] https://storage.spec.whatwg.org/ >>> [3] https://mzl.la/2GVyQ7g >>> [4] https://mzl.la/2FqW0FH >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
