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
