Install and lock an addon from using Firefox policy.
Go to AMO for that addon.
Verify the addon can be removed.
Example policy for Facebook container:
{
"policies": {
"Extensions": {
"Install": ["https://addons.mozilla.org/firefox/downloads/file/3302011/facebook_container-2.0.1-fx.xpi"],
"Locked": ["@contain-facebook"]
}
}
}
I was able to uninstall the addon.
I should not have been able to uninstall the addon.
See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1568921#c2
I'm fixing this in Firefox as a backup, but we shouldn't even show Remove on AMO in this case.
I was able to uninstall the addon.
While the AMO install button should likely not trigger the uninstall process, this should be enforced in FF too.
While the AMO install button should likely not trigger the uninstall process, this should be enforced in FF too.
Agreed. just put a fix in for that.
I took a quick look and that does not sound like an easy fix. We'll have to add a new entry in the redux state for canUninstall and fetch its value in the installAddon HOC, it's very similar to the (Firefox) add-on's status. There is no other way to retrieve the canUninstall value because it needs: (1) the Firefox add-on and (2) an async call to read canUninstall.
Hello!
While verifying bug 1568921 I observed that after selecting the Remove option from AMO page on an addon locked by policy, Add to firefox button is presented even if the add-on cannot be removed. Adding the addon again just makes and endless installing loop animation. Comment from Bugzilla here.
@AlexandruTrif is there an add-on on a hosted AMO that is locked? For example, where could I find the Grammarly add-on shown in https://bugzilla.mozilla.org/show_bug.cgi?id=1568921#c11 ?
I'd like to look into this infinite loop bug you described. That's something we should fix ASAP.
You can use policy to lock an addon:
https://github.com/mozilla/policy-templates/blob/master/README.md#extensions
@mkaply Thanks! I was able to reproduce it.
@AlexandruTrif I do not see any infinite loop in the UI. Could you be more specific? I see this on AMO:
Is that what you meant by infinite loop? If so, then that's expected since we haven't implemented any special handling of locked add-ons yet.
Hello @kumar303, sorry for the late response. By infinite loop, I meant that after clicking "Add to Firefox" and "Add" button, the animation for installing the addons remains until the page is refreshed. Here is a screen recording: link. If more information is needed please let me know. Thank you!
@AlexandruTrif thanks for clarifying. After thinking about it, I suspected that this is what you meant. The infinite animation does not create any problems, it's just annoying. We will fix it soon.
This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.
Ah, I didn't realize this would autoclose. still an issue
Please, this issue should stay open.
I am a first timer. Hope I'm welcomed here.
Where you suppose to give conditions to each of the add-ons? For example, If this, install or lock.
Hi @Medlineme4, this isn't a good issue for contributors. You'll want to get started by finding an issue labeled contrib: good first bug.
Unfortunately, we have a shortage of good first bugs at the moment and it may be a few days before more become available. You can check this list for new issues.
Thank you
Sent from Yahoo Mail on Android
On Fri, Mar 13, 2020 at 6:36 PM, Caitlin Neimannotifications@github.com wrote:
Hi @Medlineme4, this isn't a good issue for contributors. You'll want to get started by finding an issue labeled contrib: good first bug.
Unfortunately, we have a shortage of good first bugs at the moment and it may be a few days before more become available. You can check this list for new issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
@willdurand @eviljeff I am unable to reproduce the error. As mentioned above in the coments, we have to add policy to lock an addon, where I have to add that policy? Can anyone guide me on this?
@muskangupta-iitr It looks like what needs to be done to reproduce the error is described at https://github.com/mozilla/addons-frontend/issues/8418#issuecomment-519950189.
@bobsilverberg I have gone through the documentation but still facing difficulty. As I don't know where to find policies.json file or I am missing something ?
@muskangupta-iitr The instructions can be found at the top of the linked document: https://github.com/mozilla/policy-templates/blob/master/README.md. Where you put the file is different depending on your OS. Here's what it says:
"Policies can be specified using the Group Policy templates on Windows (/windows@master), configuration profiles on macOS (/mac@master), or by creating a file called policies.json. On Windows, create a directory called distribution where the EXE is located and place the file there. On Mac, the file goes into Firefox.app/Contents/Resources/distribution. On Linux, the file goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution."
I am on macOS, so I created a file called policies.json and placed in it Applications/Firefox.app/Contents/Resources/distribution/. Note that I had to create the distribution folder. Then I put the following json into the policies.json file:
{
"policies": {
"Extensions": {
"Locked": ["[email protected]"]
}
}
}
This resulted in the add-on in question (which is https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/) becoming locked.
Note that once we support the canUninstall prop in our code (in our addonManager wrapper), we could either create fake policies OR invert the condition temporarily to simulate such policies :)
Note that once we support the
canUninstallprop in our code (in ouraddonManagerwrapper), we could either create fake policies OR invert the condition temporarily to simulate such policies :)
You mean in tests, @willdurand?
You mean in tests, @willdurand?
Yes, but also in the code locally if creating a policy isn't straightforward (it does not really matter which "thing" sets the canUninstall prop to true for an add-on so we can simulate that to, for example, disable the AMInstallButton, etc.).
@muskangupta-iitr The instructions can be found at the top of the linked document: https://github.com/mozilla/policy-templates/blob/master/README.md. Where you put the file is different depending on your OS. Here's what it says:
"Policies can be specified using the Group Policy templates on Windows (/windows@master), configuration profiles on macOS (/mac@master), or by creating a file called policies.json. On Windows, create a directory called distribution where the EXE is located and place the file there. On Mac, the file goes into Firefox.app/Contents/Resources/distribution. On Linux, the file goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution."
I am on macOS, so I created a file called
policies.jsonand placed in itApplications/Firefox.app/Contents/Resources/distribution/. Note that I had to create thedistributionfolder. Then I put the following json into thepolicy.jsonfile:{ "policies": { "Extensions": { "Locked": ["[email protected]"] } } }This resulted in the add-on in question (which is https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/) becoming locked.
Thanks @bobsilverberg ! I am able to reproduce it now :+1:
@willdurand @bobsilverberg Also once I clicked the remove button and got the error the button text converts to Add to Firefox. It should be converted back when the request successfully occurred.
@willdurand @bobsilverberg Also once I clicked the remove button and got the error the button text converts to
Add to Firefox. It should be converted back when the request successfully occurred.
Yes, that is part of the problem that needs to be fixed. The button should show the correct status.
@willdurand @bobsilverberg Can I work on this issue?
I personally thought you were already working on it 🤔
@willdurand @bobsilverberg Can I work on this issue?
No. Not now at least. Please focus on what you're working on already:
I personally thought you were already working on it thinking
Yes, I started working on this but the issue is not assigned to me that's why I asked.
@willdurand @bobsilverberg Can I work on this issue?
No. Not now at least. Please focus on what you're working on already:
* #9253 * #9254
Ohk, Let us finish those issues and then I will work on others. I am just focusing on those two issues for now. These two issues are big, so I just thought to solve some small ones first :sweat_smile:
I am going to take a look at this one.
Asking for extra QA because it would be bad to break the install button :)
@willdurand I verified this with FF75 unbranded on AMO dev.
There would be 2 things I've noticed:


It looks like these two issues are related to events being sent but not handled correctly (or rather: the events are handled but don't respect the canUninstall property)
I must refresh the add-on detail page or restart the browser or else "remove" is active and when I click it I see the "An unexpected error occurred during uninstallation."
Would you have STR for this?
@willdurand I simply added the lock as @bobsilverberg suggested https://github.com/mozilla/addons-frontend/issues/8418#issuecomment-603916929. After adding the addon id in "policies.json" I opened the browser and double checked into about:policies#active. I went on the add-on page and installed it. I reproduce the issue every time.
I could file a separate issue perhaps?
@willdurand Done here -> https://github.com/mozilla/addons-frontend/issues/9365 I mentioned both scenarios.
I'm marking this issue verified on AMO dev with FF75(Win10).