User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170323105023 Steps to reproduce: I'm on firefox 52.0.2 (64 bit). says up to date. I tried to create indexedDb in this codepen: https://codepen.io/anon/pen/ybYjNK?editors=1111 Actual results: nothing happened, it logged error in console when opening indexedDb. when checking storage in developer tools, nothing is under indexedDb. Expected results: indexedDb should be created. The codepen provided seems to work in nightly and developer's edition but just not the regular version. I don't know if it's something with my local installation or if the entire batch is like this.

It seemed fixed by bug 1339081 in Nightly55.

It sounds like you're using the same Firefox profile with both nightly and stable releases of Firefox. This breaks because of the Quota Manager storage schema upgrade that Alice expertly identified. You either need to use the profile only with Firefox 55+ or use about:support's "Refresh" mechanism from Firefox 52 to reset the profile. Firefox dev edition automatically uses a separate profile which is why you wouldn't see the problem there. (This is unfortunately a known issue that bug 1246615 is trying to address, but is very slow going...)

I don't know what you mean by "profile". Are you talking about the Firefox account? If so, I will just create a new account.

(In reply to Andrew Sutherland [:asuth] from comment #2) > It sounds like you're using the same Firefox profile with both nightly and > stable releases of Firefox. This breaks because of the Quota Manager > storage schema upgrade that Alice expertly identified. You either need to > use the profile only with Firefox 55+ or use about:support's "Refresh" > mechanism from Firefox 52 to reset the profile. Firefox dev edition > automatically uses a separate profile which is why you wouldn't see the > problem there. (This is unfortunately a known issue that bug 1246615 is > trying to address, but is very slow going...) Please describe relnote or dev-doc for the profile incompatibility between 55 and earlier if any.

(In reply to Desmond from comment #3) > I don't know what you mean by "profile". Are you talking about the Firefox > account? If so, I will just create a new account. This page describes what a profile is: https://support.mozilla.org/t5/Install-and-Update/Profiles-Where-Firefox-stores-your-bookmarks-passwords-and-other/ta-p/4608 If you want to try and preserve your existing passwords, bookmarks, etc. and use the regular stable version of Firefox, then I think you want to follow the steps at https://support.mozilla.org/t5/Procedures-to-diagnose-and-fix/Refresh-Firefox-reset-add-ons-and-settings/ta-p/23405 To avoid experiencing this problem in the future, if you test with Nightly, you want to follow the steps discussed at https://support.mozilla.org/t5/Install-and-Update/Use-the-Profile-Manager-to-create-and-remove-Firefox-profiles/ta-p/2914 to use a separate profile for Nightly. I'm going to address the relnote issue in a few minutes in a separate comment.

(In reply to Alice0775 White from comment #4) > Please describe relnote or dev-doc for the profile incompatibility between > 55 and earlier if any. I don't see a relnote keyword anymore, so I'm marking dev-doc-needed for want of a better keyword. If you know the right keyword/whiteboard flag, please do correct it! The summary is basically: Firefox 55 changed the on-disk format of persistent storage in profiles. Once a profile has been used with Firefox 55 (or later), it should not be used with previous versions of Firefox. IndexedDB, the (DOM) Cache API, Service Workers, and the asm.js cache will all fail to operate, generating confusing errors and causing portions of Firefox and some websites to break. The profile can be made operable again in older versions of Firefox by using the profile "refresh" mechanism. If you want to test with both stable and nightly versions of Firefox, we recommend using separate profiles. The developer edition of Firefox automatically uses a custom profile by default.

I found the right relnote tracking flat. \o/ Andrew, I tried to put some information into the request. If I miss something, please feel free to comment, thank you thank you. :) === Release Note Request (optional, but appreciated) [Why is this notable]: There's profile incompatibility since quota manager storage schema upgrade in FF52 that caused data base not working. [Affects Firefox for Android]: yes [Suggested wording]: (simply copied from comment 6) Firefox 55 changed the on-disk format of persistent storage in profiles. Once a profile has been used with Firefox 55 (or later), it should not be used with previous versions of Firefox. IndexedDB, the (DOM) Cache API, Service Workers, and the asm.js cache will all fail to operate, generating confusing errors and causing portions of Firefox and some websites to break. The profile can be made operable again in older versions of Firefox by using the profile "refresh" mechanism. If you want to test with both stable and nightly versions of Firefox, we recommend using separate profiles. The developer edition of Firefox automatically uses a custom profile by default. [Links (documentation, blog post, etc)]:

Sounds this is a duplicate of bug 1246615? Anything we want to do in this bug?

[Tracking Requested - why for this release]: Profile once used Firefox 55 or higher, indexedDb stores will not works for older versions.

Tracking 55+ per Comment 9.

I don't think Firefox has ever supported moving profiles from a newer version to an older (i.e. using a profile created in 55 with, say, 53 or 54). So, a release note doesn't seem necessary.

Andrew, why do we even count this as a bug? As far as I know, downgrading profiles is unsupported.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #11) > I don't think Firefox has ever supported moving profiles from a newer > version to an older (i.e. using a profile created in 55 with, say, 53 or > 54). So, a release note doesn't seem necessary. (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #12) > Andrew, why do we even count this as a bug? As far as I know, downgrading > profiles is unsupported. The primary concern is people keep getting burnt by this, and it wastes both their time and those of the bug triagers and developers. Although unsupported, I'm not sure we usefully document that anywhere. And things are complicated by the breakage varying between Firefox builds/releases based on the system changes. There are many cases where downgrading across profile versions will not cause any problems. Bug 1339081 was an unusually significant change. For previous changes like IndexedDB or DOM Cache, the upgrades only impact origins specifically opened while using the "future" Firefox version. Only those origins break when returning to the "present" version. And it may be possible to recover from those breakages for content by using in-band API functionality like explicitly deleting IDB database or DOM Caches. Or by using Firefox devtools UI or other UIs to explicitly clear the storage. But Firefox Quota Manager version changes are much more significant because they break IndexedDB and DOM Cache for *all* origins and there's no way to recover without refreshing the profile. The release note would be an appreciated band-aid on the problem that bug 1246615 will hopefully address (someday). If there's a better venue that will help inform those running into this problem or who might potentially run into the problem in its particular Firefox 55 incarnation, that's definitely on the table.

Joni, is this something you can write a SUMO page for? Andrew, maybe you could write a blog post about the issues and history of this problem. And, what about MDN? I can draft a release note for 55 beta and I'll ask for your feedback for that too - it would need to be shorter and link to a longer explanation on SUMO, MDN, or a mozilla.org blog.

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #14) > Joni, is this something you can write a SUMO page for? > Andrew, maybe you could write a blog post about the issues and history of > this problem. > And, what about MDN? > I can draft a release note for 55 beta and I'll ask for your feedback for > that too - it would need to be shorter and link to a longer explanation on > SUMO, MDN, or a mozilla.org blog. indexedDb stores has been upgraded and will not works for older releases. I think this is enough for release notes. I did not find the suitable section on https://developer.mozilla.org/en-US/Firefox/Releases/55.

(In reply to YF (Yang) from comment #15) > indexedDb stores has been upgraded and will not works for older releases. > That's way too technical a description, I wouldn't understand what it means, so I doubt most users would.

Andrew or Hsin-Yi, I still think this needs a blog post, do either of you you feel up to writing one so we can link to it from the 55 beta release notes?

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #17) > Andrew or Hsin-Yi, I still think this needs a blog post, do either of you > you feel up to writing one so we can link to it from the 55 beta release > notes? I am happy to help out, but I believe Andrew could offer more details and more accurate explanation than I. I'd like to hear what he feels about it. :)

Adding "Due to changes in storage format, profiles used with Firefox 55 will no longer work with older versions of the browser" to the 55beta release notes. Suggestions for improvements are welcome.

(In reply to Julien Cristau [:jcristau] from comment #19) > Adding "Due to changes in storage format, profiles used with Firefox 55 will > no longer work with older versions of the browser" to the 55beta release > notes. Suggestions for improvements are welcome. Excellent phrasing, thanks! I would suggest adding 2 of the links I provided in comment 5 to add "how to fix this" and "how to avoid getting burnt by this in the future". Something like: To avoid this problem, use a separate profile when testing with multiple versions of Firefox as described at https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles. If you accidentally use a profile in Firefox 55beta that you would like to make work in an earlier version of Firefox again, you can follow the steps at https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings. (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #17) > Andrew or Hsin-Yi, I still think this needs a blog post, do either of you > you feel up to writing one so we can link to it from the 55 beta release > notes? I can't figure out how to make this work. There's a interesting but obvious technical reason for our inability to automatically handle downgrades. But there's no interesting technical reason for our failure to alert users or attempt to reduce the incidence of the problem by having all builds use their own channel-based profile. It's a decision being made at a different organizational level that the problem has a (de facto) low priority (by people who are looking at a bigger picture than I am). I feel like any blog post I write would be a cross between an excuse and finger-pointing that would only inflame a bad and unfortunate situation. (And read like an ad for Google Chrome, which uses different profiles for each channel per https://www.chromium.org/chrome-release-channels.) If there's anything I can add beyond my proposed additions above, please let me know. I'll comment in bug 1246615 to get an update on the status of actual fixes/mitigation, or at least a planned timeline. (It looks like the new Telemetry for decision making is in Firefox 55 per bug 1120370.)

Understood! OK, I don't think we need to keep tracking this actively for 55. It's a known issue and we have a release note with links to support pages. I also changed the bug title to be more clear, using Julien's wording. We can probably wontfix the entire bug.

(from comment #14) > Joni, is this something you can write a SUMO page for? ... and maybe a template to add a warning note to existing articles? I posted two possible warning notes in these article discussion threads (a general warning for downgrades and another for moving to Firefox 52 ESR): https://support.mozilla.org/en-US/kb/install-older-version-of-firefox/discuss/7098 [Fx55] Add note on profile breakage when downgrading from Firefox 55+ (bug 1357428) https://support.mozilla.org/en-US/kb/google-hangouts-temporarily-wont-work-on-firefox/discuss/7097[Fx55] Review/add note on possible profile issue downgrading Firefox 55+ to Firefox 52 ESR

Sorry, the second link should have been https://support.mozilla.org/en-US/kb/google-hangouts-temporarily-wont-work-on-firefox/discuss/7097

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #14) > Joni, is this something you can write a SUMO page for? Firefox 55 will be released in a few days. Joni must be unavailable since she isn't responding to this or to other NI requests. I updated https://support.mozilla.org/en-US/kb/google-hangouts-temporarily-wont-work-on-firefox/ and https://support.mozilla.org/en-US/kb/npapi-plugins for fx55+ to include a warning about possible profile issues when downgrading to Firefox 52 ESR. https://support.mozilla.org/en-US/kb/install-older-version-of-firefox/ still needs a warning. If Joni (or anyone else) creates a new SUMO page, I can link to it in those and other articles that refer to downgrading.

The non-technical information is handled properly. Thank you for that. However, the technical details about the changes in storage format are sparse at best. I do not enjoy reconfiguring extensions or wondering if I did loose some settings due to a subtle bug that now has put me open to attack or leaking private information. In addition, I should have the skills to come up with a program that gracefully downgrades a profile, without loss of information. It is after all, all just data that got moved, removed or added in places that break the old way. To develop such a script / program I would appreciate an outline as to what changed and what way. Links to commits that outline the changes would be sufficient in my case, along with a summary of breaking changes, broken down by affected component / file. Much obliged for reading and consideration.

melvyn, if you check out https://public.etherpad-mozilla.org/p/quota-manager-schema-change-log I've tried to detail which subsystems changed in which bug. The bugs will have links to the patches and the changes landed in revision control, which provides the file-level granularity you request. I only update it when I'm aware of changes; feel free to poke me at asuth@mozilla.com if you think I've missed a set of changes; also feel free to speculatively add any changes you believe are missed at a similar level of granularity. Note that in many cases, dealing with specific changes may be infeasible, such as when the structured clone representation changes. In terms of your specific use-case of not losing extension settings, the profile migration logic at https://searchfox.org/mozilla-central/source/browser/components/migration/FirefoxProfileMigrator.js used by the "refresh profile" logic at https://searchfox.org/mozilla-central/source/toolkit/modules/ResetProfile.jsm could likely be enhanced to do a better job of migrating extension settings. I could swear I had found some logic in this area relating to migrating per-extension data... but I'm not finding it right now. It definitely seems feasible for data stored in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage to be migrated if it's not already. Noting that if extensions store settings in storage.sync, those settings should already be resilient as long as Firefox sync is in use.

And when I say "could likely be better enhanced", I mean: - The functionality might already exist to some extent. - Bugs can likely be filed against the WebExtensions bugzilla components or against profile migration to improve this. As long as the bug is filed in the right general area, the WebExtensions team can probably help move the bug to the right location and or dupe it to existing bugs.

(In reply to Andrew Sutherland [:asuth] from comment #6) > (In reply to Alice0775 White from comment #4) > Firefox 55 changed the on-disk format of persistent storage in profiles. > Once a profile has been used with Firefox 55 (or later), it should not be > used with previous versions of Firefox. IndexedDB, the (DOM) Cache API, > Service Workers, and the asm.js cache will all fail to operate, generating > confusing errors and causing portions of Firefox and some websites to break. Is it possible to just delete the files on disk that store those persistent settings? If so, what files are affected?

(In reply to Alex from comment #28) > Is it possible to just delete the files on disk that store those persistent > settings? > If so, what files are affected? Yes. All Quota Manager storage lives under PROFILE/storage/, with PROFILE/storage.sqlite and PROFILE/serviceworkers.txt needing to be deleted if you delete the entire contents of that directory. In less dramatic upgrade cases that happen after Firefox 55, when downgrading, the browser console UI may list specific files that are the source of breaking problems. However, it will only log the first problem it finds, then gives up. Quota Manager storage is not used for bookmarks, history, saved passwords, session store (what tabs are open), or most other core Firefox features, so it's usually (as of this writing) safe to delete. However, various webextensions may use IndexedDB for some storage purposes, so be wary if you have a webextension that stores data you care about. Whenever doing anything to your profile directory, it's always advisable to back it up first. And for this type of problem, using the "about:support" "refresh your [firefox/nightly/etc.]" option is likely to be safest since it leaves your original profile intact and is more likely to be safe going forward. (We increasingly are moving more and more storage to QuotaManager, so at some point deleting the directory may result in meaningful data-loss.)