I'm the developer of an extension that I recently migrated from the SDK API to Web Extension API. In this extension we display an HTML page that comes from the extension itself. This page uses IndexedDB to persist some data. With the SDK I used the api tabs.open. See the actual code at [1]. This resulted to the URL resource://jid1-ie0shncwskpkjg-at-jetpack/data/results.html With the Web Extension API now I use the API tabs.create. See the actual code at [2]. The URL to the file is now moz-extension://0de43181-1da1-4948-bd51-6c0de7cd28f3/data/results.html As a result I lost all the persisted indexedDB data. Likely the same happens for localStorage too. [1] https://github.com/julienw/forms-extension/blob/9d2b8360af713c3330c6e13519540d4ce8188b5e/src/lib/main.js#L102-L110 [2] https://github.com/julienw/forms-extension/blob/a541f48d87a54ce76fe114d4f3dd61cac1eb3a5e/src/lib/main.js#L114-L116 If you want to try for yourself, you'll find all versions at [3]. v1.3.3 is a legacy extension while v1.4.0 is a Web Extension (note: updates from the browser just work). You'll have to click on the new icon, enter your mozilla credentials (note: the addon doesn't know about the auth process at all), and a new page will open. Here most editable fields (first and last name for example) are persisted accross uses of the addon. [3] https://julienw.github.io/forms-extension/ Expected: the persisted data is migrated when the extension is updated. This is important because we lose data. In the case of my add-on the data is not very important so I don't really mind, but it can be important for other extensions.

Hi Julien, The legacy extensions have access to a lot of different ways to persist their data, and so to migrate the extension data from from one (or more) of all these different kind of storage APIs the extension developer have to use an hybrid extension with an embedded webextension to transition the data from the storage APIs used in the legacy version to the storage APIs that he chose to use in the webextension. More details about this strategy can be found in the following MDN doc page and webextensions-examples: - https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Embedded_WebExtensions#Migrating_data_from_legacy_add-ons - https://github.com/mdn/webextensions-examples/tree/master/embedded-webextension-bootstrapped - https://github.com/mdn/webextensions-examples/tree/master/embedded-webextension-sdk - https://github.com/mdn/webextensions-examples/tree/master/embedded-webextension-overlay

Luca, I've been pointed to these solutions already. I'd agree in the case of extensions using specific APIs from the SDK, because that would be difficult to get it right (API change and likely format change). In the case I'm highlighting here, I'm using standard indexedDB, therefore the amount of work needed from Firefox is minimal -- likely only change the origin in the existing data -- and riskless. Moreover I'm not even sure this could work with an embedded webextension -- because in my case I believe the issue comes from an origin mismatch, but an embedded webextension wouldn't be able to access both origins (the old one and the new one). I think the bug should be reopened.

> Moreover I'm not even sure this could work with an embedded webextension -- because in my case I believe the issue comes from an origin mismatch, but an embedded webextension wouldn't be able to access both origins (the old one and the new one). An hybrid extension should be able to access both (e.g. in the scenario described in Comment 0 accessing the old one could be done: with interaction with the user by explicitly opening a tab from the legacy part of the hybrid transition extension, or without the explicit interaction from the user by using the indexed-db SDK module, while the new one can be accessed from the background page of the embedded webextension). > I think the bug should be reopened. In my opinion migrating the indexedDB automatically is not trivial as it may sound (e.g. iirc they also need to be moved physically on the filesystem, because the Firefox indexedDB data directory tree is organized by origin on the filesystem), and it is definitely not simpler than migrating the localStorage or the simple-prefs data (which are both not migrated automatically), also I'm pretty sure that it is not trivial enough to be done on Firefox 56 that is now on beta.

I agree it's likely too late for v56. We surely did more complex migrations with IndexedDB in the past :) Anyway, as I said, for my own case I don't mind, I just think this is unpleasant for our addon developers. So this is your call in the end !

Track 56- as migrating the indexedDB automatically is not trivial and won't happen in Beta56.