Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) Reporter
	Description • 10 years ago

Firefox Developer Edition 36.0a2 and Nightly 37.0a1, both 20150102

+++ This bug was initially created as a clone of Bug #1096310 +++

0. Open Firefox Developer Edition.
1. Open WebIDE.
2. Create an app (packaged, use the 'Hello World' template).
3. Close FDE.
4. Launch the profile with Nightly.
5. Open WebIDE.
Actual result:
App still shown in 'Open app' menu/dropdown.
6. Close WebIDE and Nightly.
7. Launch profile with FDE.
8. Open WebIDE.

Actual result:
App is missing from 'Open App' dropdown and the error message designed for this is not shown in the browser console:
error_appProjectsLoadFailed=Unable to load project list. This can occur if you've used this profile with a newer version of Firefox.

But there is a failing promise:

A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Date: Fri Jan 02 2015 17:42:12 GMT+0100
Full Message: undefined
Full Stack: JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: PendingErrors.register :: line 165
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.completePromise :: line 678
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: Handler.prototype.process :: line 906
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.walkerLoop :: line 749
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.scheduleWalkerLoop/< :: line 691
native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0 <unknown>
1420216965735	Services.Metrics.Provider.org.mozilla.addons	WARN	Add-on type without field: dictionary
1420216965952	Services.HealthReport.HealthReporter	WARN	Recording new remote ID: d4e83409-7aba-42d9-8951-0aedfde5a481
1420216966801	Services.HealthReport.HealthReporter	WARN	Marking upload as successful.
1420216966801	Services.HealthReport.HealthReporter	WARN	Removing documents from remote ID list: 921f7ddf-af14-4d20-b100-4e820df422ce

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 1 • 10 years ago

Let's say you open a profile in 36 and add project A in WebIDE.

When a profile is moved from 36 -> 37, IndexedDB migrates data from <PROFILE>/storage/persistent to <PROFILE>/storage/permanent (as part of bug 1083927).  So, 37 will also show project A in WebIDE.

If you then go back to 36, the old location is now "free" after the migration, so an entirely new DB is created in the old location.  So, WebIDE's project list is now empty.  You could add something else, like project B.

If you go forward once more to 37 (as comment 0 details), IndexedDB appears to ignore the old 36-format location, since there is already data in the new 37-format location.  So, you'll only see the list with project A.

I don't believe there is any way for content to detect this split-brain state, so it's hard for WebIDE to do much at the moment.

The error message you found in WebIDE is meant to cover cases where IndexedDB throws an exception, but following these steps, it appears there is no content-detectable error, so no message is displayed.

Jan, in the general case of these IndexedDB changes per Gecko version, should / could IndexedDB do a better job in these kind of situations?  I know version compatibility is hard, but many Mozilla developers and contributors move profiles back and forth all the time, as it (appears to) generally work, except for IndexedDB.

At this point, I am tempted to "backup" WebIDE's data to a snapshot file outside of IndexedDB to attempt to cover more cases where IndexedDB acts unexpectedly... but I would really rather not have to do that work if possible.

	Jan Varga [:janv]
	Comment 2 • 10 years ago

Well, going back to an older version is not officially supported, but I agree that stuff should work if you switch back, in other words, going back shouldn't corrupt storage locations or databases from the point of view of newer releases. However, if I understood it correctly, this bug is not about broken storage location, you would like to see projects added in 36 to also appear in 37 after the storage location was already done. I believe this is not solvable easily and as I said going back is not officially supported.
IndexedDB itself needs sometimes to upgrade internal database schema, so even if we fixed quota manager, there could be a case when IndexedDB refuses to work.
Hopefully, similar storage location upgrades won't happen too often.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 3 • 10 years ago

Okay, it's good to know at least that this backward movement is not officially supported.

And you are right, IndexedDB itself could have upgraded the schema too, so that would result in similar issues.

So, overall I am not sure there is much that WebIDE can do here.  However, I filed bug 1118816 to consider tracking when a profile moves backward, as that would hopefully allow us to display this warning message in more situations.

	Jan Varga [:janv]
	Comment 4 • 10 years ago

Yeah, a warning would be nice.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 5 • 7 years ago

Apps are being removed with B2G cleanup.