692862 - Allow installation of application wide extensions but block distributions

Status: RESOLVED FIXED

(Testing :: Mozbase, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Right now we only allow the installation of add-ons from the profile folder. Reason was that globally installed add-ons are causing major trouble especially when it comes to update tests. But one thing we haven't taken care of is that we have to differentiate between add-ons in the application and distribution scope. The result right now is, that the default theme is not listed in the appearance pane of the add-ons manager.

Here the proposal from Dave (copied from bug 672480 comment 13):

extensions.installDistroAddons=false will disable installing distribution add-ons
extensions.enabledScopes=5 will disable all extension locations except for the profile and the application (where the default theme is).

Some of the partner repacks may still be using the application location for their bundled add-ons. In that case there is currently no way to not install those add-ons but keep the default theme.


I think that we do not have to take care that much about possible add-ons for partner repacks. It's not something we support at the moment; which doesn't mean that we shouldn't.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Patch v1 (1.5.x)

As it turns out we already have the preference 'extensions.installDistroAddons' set to false due to another bug. The only required change here really is to allow the installation of add-ons from the application scope. We already had that before but accidentally flipped to the profile scope only, which was a mistake because it will hide the default theme.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Patch v1 (2.0)

Comment 3

[Jeff Hammel]

Comment on attachment 565717 [details] [diff] [review]
Patch v1 (1.5.x)

works for me.  it would be nice to link to something that actually tells what this does (yes, I know you already have it in the comment).

Comment 4

[Jeff Hammel]

Comment on attachment 565718 [details] [diff] [review]
Patch v1 (2.0)

wfm

Comment 5

[Jeff Hammel]

pushed to master: https://github.com/mozautomation/mozmill/commit/9be9ebdb5278b03becbdb3384a9c20ccf8faebcf

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Clint, it would be great to get an approval for hotfix-1.5. For now this bug blocks one of our tests. More probably coming.

Comment 7

[cmtalbert]

(In reply to Henrik Skupin (:whimboo) from comment #6)
> Clint, it would be great to get an approval for hotfix-1.5. For now this bug
> blocks one of our tests. More probably coming.

Since you've already got the patch, land away.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Landed as:
https://github.com/mozautomation/mozmill/commit/7bfcf46a5ed348c4037a8ac225e0f30028da7064

Comment 9

[Maniac Vlad Florin (:vladmaniac)]

This is verified with Mozmill 1.5.6 - should we mark as verified fixed or wait until mozmill 2.0 lands?

Comment 10

[cmtalbert]

(In reply to Maniac Vlad Florin (:vladmaniac) from comment #9)
> This is verified with Mozmill 1.5.6 - should we mark as verified fixed or
> wait until mozmill 2.0 lands?

For bugs that span two branches, we generally use whiteboard flags to indicate verified and use the main status to indicate the status of the resolution on the latest branch.  (So, when verified against 2.0, we'd move it to status verified).  Thanks for verifying it!!!