809772 - Installing a packaged app from the browser/app seems broken

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect, P1)

Description

[Julien Wajsberg [:julienw]]

* 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}]

Comment 1

[Julien Wajsberg [:julienw]]

nominating for basecamp as this seems like something we need.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gaia triage : P2 as it has regressed, +

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 4

[Julien Wajsberg [:julienw]]

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

Comment 5

[[:fabrice] Fabrice Desré]

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

Comment 6

[Julien Wajsberg [:julienw]]

added the good email address for francisco

Comment 7

[Alex Keybl [:akeybl]]

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

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 10

[Jason Smith [:jsmith]]

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

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

(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.

Comment 12

[Jason Smith [:jsmith]]

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.

Comment 13

[Jason Smith [:jsmith]]

(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.

Comment 14

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

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.

Comment 15

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 17

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6462

Pointer to Github pull-request

Comment 18

[Jason Smith [:jsmith]]

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

Comment 19

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 20

[Jason Smith [:jsmith]]

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

Comment 21

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 22

[Fernando Jiménez Moreno [:ferjm]]

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

Comment 23

[Antonio Manuel Amaya Calvo (:amac)]

(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.

Comment 24

[Fernando Jiménez Moreno [:ferjm]]

(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.

Comment 25

[Fernando Jiménez Moreno [:ferjm]]

https://github.com/mozilla-b2g/gaia/commit/82fe7727db55ad66098858b1edf846841e8481e5

Comment 26

[Jason Smith [:jsmith]]

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

Comment 27

[sarsenyev]

Verified on "Unagi"
Build ID:20130112070202

The packaged application is displayed on the main screen and launched.