Bug 1050080 needs to be ported to mobile to unbreak add-on/LWT/app installation (perhaps just in new profiles). I missed that android's browser.js was overlooked while reviewing bug 1050080. I notice that bug 506446 hardcoded a path of "resource://app/chrome/browser/default_permissions" for the default location but I don't know if that works for android. Requesting tracking since this needs to be fixed in 35 or else we may want to backout 1050080? MXR search: https://mxr.mozilla.org/mozilla-central/search?string=whitelist.add

I'll write the patch if you tell me where you want the file and what the resource URI would be for it? :P We're probably going to backout part of bug 1050080 when markh is online.

(In reply to Matthew N. [:MattN] from comment #1) > I'll write the patch if you tell me where you want the file and what the > resource URI would be for it? :P Looks like we are trading permissions that can be distributed across various JS preference files for a single file at a single location. This makes setting common permissions in toolkit and app permissions in the app difficult. The current single location is: "resource://app/chrome/browser/default_permissions" but can be overridden using a preference (mainly for testing): "permissions.manager.defaultsUrl" A better single location might be: "resource://app/default_permissions" the default_permissions file for each app will need to copy/fork the toolkit permissions, right? But Fennec should not have the uitour permissions for example.

(In reply to Mark Finkle (:mfinkle) from comment #2) > (In reply to Matthew N. [:MattN] from comment #1) > > I'll write the patch if you tell me where you want the file and what the > > resource URI would be for it? :P > > Looks like we are trading permissions that can be distributed across various > JS preference files for a single file at a single location. This makes > setting common permissions in toolkit and app permissions in the app > difficult. Right, I made the same comments but others (I think Gavin and MarkH at the Toronto work week) didn't think it was a big deal given the current consumers. > The current single location is: > "resource://app/chrome/browser/default_permissions" > > but can be overridden using a preference (mainly for testing): > "permissions.manager.defaultsUrl" > > A better single location might be: "resource://app/default_permissions" I filed bug 1073095 earlier for the default location be less than ideal. Perhaps "resource://app/defaults/" would also be good. > the default_permissions file for each app will need to copy/fork the toolkit > permissions, right? But Fennec should not have the uitour permissions for > example. Right, I was planning on making a new file somewhere in /mobile/ that had only the xpinstall permissions. Do you think this should depend on bug 1073095? I was just going to use the override pref for now.

(In reply to Matthew N. [:MattN] from comment #3) > > A better single location might be: "resource://app/default_permissions" > > I filed bug 1073095 earlier for the default location be less than ideal. > Perhaps "resource://app/defaults/" would also be good. Yeah > > the default_permissions file for each app will need to copy/fork the toolkit > > permissions, right? But Fennec should not have the uitour permissions for > > example. > > Right, I was planning on making a new file somewhere in /mobile/ that had > only the xpinstall permissions. Do you think this should depend on bug > 1073095? I was just going to use the override pref for now. Using the override pref for this bug is fine, but let's make sure we change it when bug 1073095 lands.

(In reply to Mark Finkle (:mfinkle) from comment #2) > Looks like we are trading permissions that can be distributed across various > JS preference files for a single file at a single location. This makes > setting common permissions in toolkit and app permissions in the app > difficult. Benjamin and I felt this could be considered a build-time issue when the need arises (ie, by concatenating permission files from different locations into the single file packaged with the app). As Matt says, given the current consumers we felt it wasn't necessary to implement this build-time part now - maybe that was naive.

Yeah, sorry, it was Benjamin, not Gavin. I don't think it's a good use of my time to revive my android build environment and learn about the android build packaging in order to add a file especially now that Android isn't broken anymore.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.