All users were logged out of Bugzilla on October 13th, 2018

Installing a packaged app from the browser/app seems broken

VERIFIED FIXED

Status

P1
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: julienw, Assigned: ferjm)

Tracking

unspecified
x86_64
Linux

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
* 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}]
(Reporter)

Comment 1

6 years ago
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?
(Reporter)

Comment 4

6 years ago
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
(Reporter)

Comment 6

6 years ago
added the good email address for francisco

Comment 7

6 years ago
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)
(Assignee)

Comment 8

6 years ago
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.

Updated

6 years ago
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?
(Assignee)

Comment 11

6 years ago
(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
(Assignee)

Comment 15

6 years ago
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

Updated

6 years ago
Duplicate of this bug: 811146

Updated

6 years ago
Summary: Installing a packaged app from the browser seems broken → Installing a packaged app from the browser/app seems broken

Updated

6 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(Assignee)

Updated

6 years ago
Blocks: 802574
OS: Gonk (Firefox OS) → Linux
Hardware: ARM → x86_64
(Assignee)

Comment 17

6 years ago
Created attachment 682444 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/6462

Pointer to Github pull-request
(Assignee)

Updated

6 years ago
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
(Assignee)

Updated

6 years ago
Attachment #682444 - Flags: review?(francisco.jordano)
(Assignee)

Comment 19

6 years ago
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
(Assignee)

Comment 21

6 years ago
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.
(Assignee)

Comment 22

6 years ago
(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.
(Assignee)

Comment 24

6 years ago
(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.
(Assignee)

Updated

6 years ago
Attachment #682444 - Flags: review?(francisco.jordano)
Attachment #682444 - Flags: review?(francisco.jordano) → review+
(Assignee)

Comment 25

6 years ago
https://github.com/mozilla-b2g/gaia/commit/82fe7727db55ad66098858b1edf846841e8481e5
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
See Also: → bug 813468

Updated

6 years ago
Keywords: verifyme
qa- for verification in favor of testing the finalized fix in bug 813468
Keywords: verifyme
Whiteboard: [qa-]

Updated

6 years ago
Whiteboard: [qa-]

Updated

6 years ago
Whiteboard: [qa-]

Comment 27

6 years ago
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.