I have 20 apps installed on my Mac from last week's Nightly. Today I updated Nightly and none of the apps will run. Their icon briefly appears in the dock and then disappears right after.
I have discovered that this was due to old apps having a different installrecord format than new ones. Force a reinstall of the old apps and a new install record should be written and the app should work again.
From bug 746771?
Yeah, new installs work fine. As we're planning to allow real users to begin installing apps pretty soon, are there any other changes like this planned? We should probably lock this down.
(In reply to Justin Scott [:fligtar] from comment #3)
> Yeah, new installs work fine. As we're planning to allow real users to begin
> installing apps pretty soon, are there any other changes like this planned?
> We should probably lock this down.
We aren't planning other changes, nor did we plan this one, which was due to a bug in one of the patches for the initial implementation. However, during the current phase of development, when the feature is only in nightly builds, we can't absolutely rule it out.
I'm not sure though how the change from bug 746771 could have caused that
Hmm, indeed, Felipe is right. Bug 746771 is not the cause of this problem, because the registryDir property (née app.profile) is not in the startup path of the runtime, so the absence of the property would not prevent startup.
It's not the runtime that is failing, as far as I can tell. Firefox is failing to load the webapp. The webapprt launcher completes, and sends the correct command line to Firefox and exits with no errors.
fligtar: can you attach an archive of the app package (i.e. /Applications/Name.app) for one of the failing apps to this bug and then email Dan and I a copy of its data dir (i.e. ~/Library/Application Support/[origin]/)?
fligtar: erm, never mind, you already provided Dan with this information, and he has provided it to me!
For tracking purposes, Justin, could you still attach the archive of the app package to this bug? I'll want to know what I need to test when verifying this bug after it is fixed.
With the files fligtar provided, I dug into this and figured out that it's a regression from the combination of bug 746771, which fixed a bug in the way an app identifies the webapp registry, and bug 746213, which puts identification of the webapp registry into the startup path of the runtime, specifically into the CommandLineHandler component, via an attempt to import the Webapps.jsm module.
When imported, that module tries to retrieve its datastore directory. If that attempt throws an exception, as it might for apps installed before the fix for bug 746771 landed, the exception propagates through the component and up to the component loader, which writes an error like this one to the console:
JS Component Loader: ERROR resource://gre/modules/FileUtils.jsm:60
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]
The GRE then exits because it needs the command line handler to start the app.
A naive fix (catch the exception) is trivial, and I'll implement one if needed, although I'd like to think a bit about how best to fix this first, since it'll happen under other circumstances beside the one that triggered this bug (f.e. if the user deletes and recreates their profile).
jsmith: no need to get the archive from fligtar; you can test this with any app. Just open its webapp.json file and remove the registryDir property.
For tracking purposes, this bug will relate the Mac issue fligtar hit.
Created attachment 618485 [details] [diff] [review]
patch v1: naive fix
Here's the naive fix, which is worth taking even while we figure out how to make this better.
Myk, I'm trying to understand this bug, let me know if I got it right:
it happened after the fix for bug 746213, which makes it try to read the .json file, and happens only to apps installed before the fix for bug 746771 (i.e. ones that do not contain registryDir).
If so, technically we don't need to do anything to fix this bug, and you're adding this try catch to prevent a similar problem from happening in the future. Is that right?
That's just about right, except that this patch does fix the problem for those old installs in addition to preventing a similar problem from happening in the future. I want a better fix in the future as part of a general improvement to registry initialization that has these characteristics:
1. continues to prevent failure in registry initialization from affecting startup;
2. makes registry initialization more robust against changes to the location of the user's default profile;
3. makes registry initialization asynchronous.
But I think this patch is worth taking in the meantime.
Comment on attachment 618485 [details] [diff] [review]
patch v1: naive fix
yeah, we're gonna have to think of a better mechanism in the future, maybe versioning the format. The problem is that when this happens, the profile data will be unavailable to the app, right? So a lot of things on the app won't work even if it loads up. And the config file won't fix itself.. so we might have to trigger a file update
The app profile (and datadir generally) remains available, it's just the Firefox profile that becomes unavailable. And the app's install record and manifest are copied to its datadir on installation. So most apps will work just fine.
The exception is apps like Marketplace that use the app management API to install, uninstall, etc. apps. Those need access to the registry in order to do that work.
Also, in the future, we might start sharing other Firefox profile data with apps besides the registry, like proxy settings, in which case other app functionality might break when the Firefox profile becomes unavailable.
We'll need to do some hard thinking about what information we want to share and how to do it (which may involve moving it out of the profile directory, so it isn't profile-specific, and/or sharing it via a service).
Clarification - To verify this bug, I need to grab a nightly build from around 4/17, install apps, update to the latest nightly, and verify I can run them, correct? Or is there something else I should be doing?
(In reply to Jason Smith [:jsmith] from comment #20)
> Clarification - To verify this bug, I need to grab a nightly build from
> around 4/17, install apps, update to the latest nightly, and verify I can
> run them, correct? Or is there something else I should be doing?
That sounds right!
Verified on OS X 10.7.