Closed Bug 809772 Opened 8 years ago Closed 8 years ago

Installing a packaged app from the browser/app seems broken

Categories

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

x86_64
Linux
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: julienw, Assigned: ferjm)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file)

* 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.
blocking-basecamp: --- → ?
Gaia triage : P2 as it has regressed, +
blocking-basecamp: ? → +
Priority: -- → P2
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".
Target Milestone: --- → B2G C2 (20nov-10dec)
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.
Duplicate of this bug: 811748
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.
blocking-basecamp: + → ?
Component: Gaia::Browser → Gaia
Priority: P2 → --
Target Milestone: B2G C2 (20nov-10dec) → ---
(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.
Assignee: nobody → francisco.jordano
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.
Assignee: francisco.jordano → ferjmoreno
Duplicate of this bug: 811146
Summary: Installing a packaged app from the browser seems broken → Installing a packaged app from the browser/app seems broken
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Blocks: app-install
OS: Gonk (Firefox OS) → Linux
Hardware: ARM → x86_64
Attachment #682444 - Flags: review?(francisco.jordano)
The person running the smoke tests couldn't reproduce this bug. Marking for retest.
Keywords: qawanted
QA Contact: jsmith
Attachment #682444 - Flags: review?(francisco.jordano)
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.
Keywords: qawanted
blocking-basecamp: ? → +
Priority: -- → P1
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.
Attachment #682444 - Flags: review?(francisco.jordano)
Attachment #682444 - Flags: review?(francisco.jordano) → review+
https://github.com/mozilla-b2g/gaia/commit/82fe7727db55ad66098858b1edf846841e8481e5
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
See Also: → 813468
Keywords: verifyme
qa- for verification in favor of testing the finalized fix in bug 813468
Keywords: verifyme
Whiteboard: [qa-]
Whiteboard: [qa-]
Whiteboard: [qa-]
Verified on "Unagi"
Build ID:20130112070202

The packaged application is displayed on the main screen and launched.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.