* go to http://everlong.org/mozilla/packaged/ with the browser * click the button * click "install" The application doesn't display on the homescreen. However, after restarting the phone it is present, but it can't be launched. I get the following error using adb logcat : E/GeckoConsole( 505): [JavaScript Error: "Applications.getManifest(...) is null" {file: "app://homescreen.gaiamobile.org/js/grid.js" line: 669}] E/GeckoConsole( 505): [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: '[JavaScript Error: "Applications.getManifest(...) is null" {file: "app://homescreen.gaiamobile.org/js/grid.js" line: 669}]' when calling method: [nsIDOMEventListener::handleEvent]" {file: "jar:file:///system/b2g/omni.ja!/components/Webapps.js" line: 716}] E/GeckoConsole( 468): [JavaScript Error: "Applications.getManifest(...) is null" {file: "app://homescreen.gaiamobile.org/js/grid.js" line: 669}] E/GeckoConsole( 468): [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: '[JavaScript Error: "Applications.getManifest(...) is null" {file: "app://homescreen.gaiamobile.org/js/grid.js" line: 669}]' when calling method: [nsIDOMEventListener::handleEvent]" {file: "jar:file:///system/b2g/omni.ja!/components/Webapps.js" line: 716}] E/GeckoConsole( 468): [JavaScript Error: "this is undefined" {file: "resource://gre/modules/Webapps.jsm" line: 1283}]

nominating for basecamp as this seems like something we need.

Gaia triage : P2 as it has regressed, +

Fabrice, could you try to take a look at the logcat to see if there's anything that stands out please?

the "Applications.getManifest(...) is null" is actually a problem in the homescreen, I think Francisco is already having a look on this.

The "this is undefined" part is a dupe of bug 809998

added the good email address for francisco

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".

One of the reasons for packaged apps not being properly installed was that the platform was not properly sending the manifest information along with the 'ondownloadsuccess' event. This have been solved in Bug 809948. It seems that the rest of the work is on the Gaia side. Francisco and me will be looking into this.

Fernando - Would packaged app installation also be broken if I tried to install it through an app instead of the browser?

(In reply to Jason Smith [:jsmith] from comment #10) > Fernando - Would packaged app installation also be broken if I tried to > install it through an app instead of the browser? Yes, I am afraid that it would also be broken.

Renoming to increase priority from P2 to P1 - this is going to block the marketplace guys from being able to test packaged apps integration they have on device. We can't keep those guys blocked on development.

(In reply to Jason Smith [:jsmith] from comment #12) > Renoming to increase priority from P2 to P1 - this is going to block the > marketplace guys from being able to test packaged apps integration they have > on device. We can't keep those guys blocked on development. Note - although this isn't called out as a smoke test in our smoke tests yet, I am likely going to push for this being a smoke test in our next revision of smoke tests. For clarity - that's the level of severity I'm arguing, cause this is fundamental apps functionality that needs to be always working.

Francisco I believe this will be part of your [App Install] work. Assigning to you but feel free to re-assigned if I'm wrong.

Actually, I am working on this :). I have a WIP fix for the issue and will be sending a PR after https://github.com/mozilla-b2g/gaia/pull/6427 lands.

Pointer to Github pull-request

The person running the smoke tests couldn't reproduce this bug. Marking for retest.

Packaged app installation works fine in b2g-desktop with the attached patched but randomly fails in the device with the following error: "E/GeckoConsole( 3026): [JavaScript Error: "NS_ERROR_FILE_ACCESS_DENIED: File error: Access denied" {file: "app://homescreen.gaiamobile.org/js/page.js" line: 146}]" I am trying to debug the cause.

Yeah I can reproduce this. Don't know why the smoke test didn't catch this.

I might have found the root cause of the issues installing package apps in the device. It seems that the application data is being saved in '/data/local/webapps/' with 600 permissions for user:group 'root:root', while it is supposed to be saved, at least, with 644 permissions. While running OOP the app process is owned by the 'app_0' user, so for the case of the homescreen, which is trying to get the application icon stored in '/data/local/webapps/{appId}/', it does not have enough permissions to read any data and so it fails with the 'NS_ERROR_FILE_ACCESS_DENIED' error. That means that the attached Gaia patch is probably enough, as it works in b2g-desktop or disabling OOP in the device. I'll be uploading a platform patch to fix the permissions issue as soon as possible.

(CCing Antonio Amaya) Antonio, how do you feel about this permissions change in terms of security?

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #22) > (CCing Antonio Amaya) > Antonio, how do you feel about this permissions change in terms of security? This means the content processes must have permission to access the installation directories for the apps. I will have to check what use restrictions do the jar: protocol enforce. It would be a better solution from a security point of view, though, to have the app: protocol be served by the main process instead of the child processes. This way we wouldn't have to take this kind of compromises. One of the reasons to have multiple content process after all was restricting the possible damage in case one is compromised.

(In reply to Antonio Manuel Amaya Calvo from comment #23) > (In reply to Fernando Jiménez Moreno [:ferjm] from comment #22) > > (CCing Antonio Amaya) > > Antonio, how do you feel about this permissions change in terms of security? > This means the content processes must have permission to access the > installation directories for the apps. > I will have to check what use restrictions do the jar: protocol enforce. > > It would be a better solution from a security point of view, though, to have > the app: protocol be served by the main process instead of the child > processes. This way we wouldn't have to take this kind of compromises. One > of the reasons to have multiple content process after all was restricting > the possible damage in case one is compromised. I am afraid that changing the permissions of the packaged app files to 644 didn't work :(. However, I still think that this permissions change is required if we are supposed to access this files from the content process. Other option is to make the app: protocol be served by the main process as you said. I talked to Dietrich and Jason Smith on IRC and we agreed to merge the Gaia side to unblock testing of packaged apps installation (at least running without OOP). I've filed Bug 813468 to continue tracking the work required to make packaged apps installation to work when running OOP.

qa- for verification in favor of testing the finalized fix in bug 813468

Verified on "Unagi" Build ID:20130112070202 The packaged application is displayed on the main screen and launched.