Bug 1275496 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I understand there to be 2 things going on:
1. Removing support for the storage attribute in the options dictionary.  This is tracked by bug 1354500.  And it's what the pref "dom.indexedDB.storageOption.enabled" is about.  The attribute will be ignored if you're not using the system principal or an addon principal and the preference is not set.  However, callers can still use it.
  - We added a deprecation warning in bug 1442560 that shipped in Firefox 60 on May 7th, 2018.
  - We sent an intent to unship "storage" attribute in the options dict: https://groups.google.com/d/msg/mozilla.dev.platform/3b700_oeAzo/4hzZDEJQCwAJ on March 6, 2018.
  - This is the only thing we've been gathering telemetry on.
2. Removing support for the options dictionary.  I don't think we're actually pursuing this yet, and it's fairly likely the IDB spec will end up using this signature in the future, so it's not clear it's worth trying to remove it at this time.  We could certainly start gathering telemetry on the usage to be able to move forward on removing support for the options dictionary.  We would want to make sure to either filter out or bin separately chrome principal and addon-principal usages.  Perhaps also distinguish when "file" schemes are using IndexedDB, as we've seen evidence of Firefox being used directly for kiosk-type applications where Firefox's implementation may be assumed.  (We may not get telemetry from these, however...)
  - Specifically, it's clear we want to use multiple storage buckets (https://github.com/whatwg/storage/issues/2) but it's not clear that we've decided how to expose them and how they'll interact with existing APIs.  The two obvious directions are expanding each API so that IDBFactory.open() could take an options dict of { bucket: "bucket name" } or having `navigator.storage.getBucket("bucket name")` exist that returns an object with an IDBFactory on it.
I understand there to be 2 things going on:
1. Removing support for the storage attribute in the options dictionary.  This is tracked by bug 1354500.  And it's what the pref "dom.indexedDB.storageOption.enabled" is about.  The attribute will be ignored if you're not using the system principal or an addon principal and the preference is not set.  However, callers can still use it.
    - We added a deprecation warning in bug 1442560 that shipped in Firefox 60 on May 7th, 2018.
    - We sent an intent to unship "storage" attribute in the options dict: https://groups.google.com/d/msg/mozilla.dev.platform/3b700_oeAzo/4hzZDEJQCwAJ on March 6, 2018.
    - This is the only thing we've been gathering telemetry on.
2. Removing support for the options dictionary.  I don't think we're actually pursuing this yet, and it's fairly likely the IDB spec will end up using this signature in the future, so it's not clear it's worth trying to remove it at this time.  We could certainly start gathering telemetry on the usage to be able to move forward on removing support for the options dictionary.  We would want to make sure to either filter out or bin separately chrome principal and addon-principal usages.  Perhaps also distinguish when "file" schemes are using IndexedDB, as we've seen evidence of Firefox being used directly for kiosk-type applications where Firefox's implementation may be assumed.  (We may not get telemetry from these, however...)
    - Specifically, it's clear we want to use multiple storage buckets (https://github.com/whatwg/storage/issues/2) but it's not clear that we've decided how to expose them and how they'll interact with existing APIs.  The two obvious directions are expanding each API so that IDBFactory.open() could take an options dict of { bucket: "bucket name" } or having `navigator.storage.getBucket("bucket name")` exist that returns an object with an IDBFactory on it.

Back to Bug 1275496 Comment 13