James Burke [:jrburke] Reporter
	Description • 10 years ago

This is related to bug 1018534, allowing the email app to be a "privileged" instead of "certified" app:

Bug 1014410 allowed the privileged app when installed as part of device install to not prompt for privileges.

However, for tests, at least for the integration/marionettejs tests, the permission prompts show up, breaking the tests.

Ideally, the permissions could be seeded correctly so that the permission prompts would not show up for the tests in the app (at least for permissions like Contacts that can be set to ALLOW automatically).

I am unclear if this is a gecko/gaia runtime change that needs to happen or something that needs to be set up inside the profile directory used for tests.

Steps to reproduce:

* Edit apps/email/manifest.webapp and change "type": "certified" to "type": "privileged"
* Run the gaia marionettejs tests for email.

The permission dialog for access to contacts blocks the test from proceeding.

	James Burke [:jrburke] Reporter
	Comment 1 • 10 years ago

For this issue, :vingtetun in IRC pointed out that this method:

http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#394

Likely needs to return true. 

When I look at that function in the B2G build for the tests, it is an empty function, presumably since #ifdef MOZ_WIDGET_GONK is not true since these tests run on a desktop computer. If I manually edit that file locally and insert a return true for that method, then the tests work without getting the prompt.

Asking :amac if there are ideas on a fix based on that information. I am very new to this code, but my first guess at an else case that just returns true is probably not correct. Perhaps also this is just the wrong place to fix this issue, and it just happens to override a deeper issue.

	Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
	Comment 2 • 10 years ago

As said on IRC, you likely need to return |true| in http://hg.mozilla.org/mozilla-central/annotate/16f3cac5e8fe/dom/apps/src/Webapps.jsm#l393

This code use a #ifdef MOZ_WIDGET_GONK since preinstalled apps lives under /system/b2g/webapps on the device, where normal apps lives under /data/local/webapps.

It seems like the code that configure the permissions use App.isPreinstalled in order to configure the default permissions (see http://hg.mozilla.org/mozilla-central/annotate/349a2f003529/dom/apps/src/PermissionsInstaller.jsm#l154)

On a desktop build the situation is a bit different since all apps lives in $PROFILE_FOLDER/webapps. This is a bit tricky to just return |true| in this method on desktop since all privileged apps that are installed after the first run will see all their permissions that are normally set to prompt to be granted on an update.

Not sure what is the right fix here. One simple and dirty fix would be to return true here only if this is the first run of Gecko. That does not match exactly what is on the device, but at least it will solve your use case.

A better fix would be to have a $PROFILE_FOLDER/core/webapps folder in the profile that contains the default set of apps, and so the code can be fixed in order to look here for platform that are not based on gonk. 

If you want to move |privileged| in 2.0 in order to let us enable the CSP properly, I would recommend to go with the first solution, and open a followup to implement the second solution.

	James Burke [:jrburke] Reporter
	Comment 3 • 10 years ago

Some more notes with :vingtetun from IRC:

> you likely need to fix the AppsUtils.isFirstRun method, and split it into 2 methods. One for AppsUtils.isUpdate and one for AppsUtils.is(Really)FirstRun
> the way to look at that is a bit weak
> but you can determine that this is a first run if the prefs in the first run method does not have an user value
> like http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/sites.js#196

As this intermediate patch seemed to get more involved, and a fuller fix is likely best, I instead just modified the email tests to deal with the permission in the pull request for bug 1018534.

So this no longer blocks that bug, and I will leave this open to track a full fix, separate from the email work.

	Antonio Manuel Amaya Calvo (:amac)
	Comment 4 • 10 years ago

I think it's even more complicated than that. Or maybe simpler. Besides that function being empty on desktop, there's also http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#93. On a desktop build (on a non B2G build actually) the permissions should not be installed. This and the other problem should be tackled on bug 1016889.

	BMO Automation
	Comment 5 • 7 years ago

Firefox OS is not being worked on