Closed Bug 1236557 Opened 10 years ago Closed 10 years ago

IndexedDB database created in newer version of Firefox can't be opened in older version of Firefox

Categories

(Core :: Storage: IndexedDB, defect)

44 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox43 --- unaffected
firefox44 - wontfix
firefox45 - wontfix
firefox46 - wontfix

People

(Reporter: drew, Unassigned)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151223140742 Steps to reproduce: 1) Host this simple web page somewhere: <script> var request = indexedDB.open('lp'); request.onerror = function(e) { alert('error'); } request.onsuccess = function(e) { alert('success'); }; </script> 2) Navigate to it in Firefox nightly. 3) Close Firefox Developer Edition and navigate to it in Firefox production. Actual results: The database can't be opened (you'll see an error alert). Expected results: The database should be able to be opened (you'll see a success alert).
I meant Firefox nightly in step 3 (Firefox Developer Edition might not cause the problem, since it uses a separate profile by default).
The error in the browser console is: IndexedDB Unable to open IndexedDB database, schema is too high!: ActorsParent.cpp:4466
Component: Untriaged → DOM: IndexedDB
Product: Firefox → Core
Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=001f7d3139ce06e63075cb46bc4c6cbb607e4be4&tochange=b0380aa2d9c2a0064272840a922c35f0a482113b (I needed to run Mozregression with a custom profile, create IDB, close the nightly then reopen the custom profile with the current FF43 to read the IDB) Nick Fitzgerald — Bug 1201620 - Make SavedFrame stacks structured cloneable; r=sfink
Blocks: 1201620
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(nfitzgerald)
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Version: 43 Branch → 44 Branch
This is expected. We've never supported downgrading across schema changes, and don't intend to in the future.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(nfitzgerald)
That seems pretty bad... So if a user switches back and forth between Firefox production and nightly, it's expected that any IndexedDB databases in use by websites and/or extensions will cease to work in Firefox production?
Flags: needinfo?(khuey)
That's correct. In general the schema changes are not backwards compatible. Each one usually corresponds to the addition of a new feature, so anything that used that feature can't be downgraded. Developer Edition uses a separate profile precisely for this switching back and forth case, but we don't really support that between nightly and release. If you use separate profiles in nightly and release you won't have any problems.
Flags: needinfo?(khuey)
Though I have no interest in implementing forward-compatibility, I've always been a little nervous about this. I don't suppose we have any UI that says "WHOA DUDE. It looks like you're trying to open up an IndexedDB created with a newer version of the browser. That's not gonna work. Would you like to use the old backup copy we saved when you upgraded?"
No, we don't have any UI, and we don't save any backups. It just fails.
If there's an argument for UI enhancement, it's in the profile manager/startup path to say: "Whoa, whoa, whoa. I see this profile is normally used with stable/devtools/aurora Firefox. Are you sure you to run it in nightly? Once you've been to the future, there's no going back." That protects all gecko subsystems from massively complicating themselves and introducing serious disk usage and privacy issues. And of course is a bug for another component.
I thought we could try the fancy new platform-UX mailing list with a discussion about this: https://groups.google.com/d/msg/mozilla.dev.platform.ux/RV01AFaozJQ/Gkl3dqtHCAAJ
This clearly looks like a wontfix for FF44. I am in favor of a UI enhancement/message that informs users and gives them a choice of what to do next as mentioned in comment 7 (with slightly better wording :)
Since we wontfixed this, dropping the tracking requests for 45+. A warning for users who try this seems like a great idea.
See Also: → 1269026
You need to log in before you can comment on or make changes to this bug.