Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100430 Minefield/3.7a5pre (.NET CLR 3.5.30729) Upgraded to Firefox with new add-ons manager, chose Extensions pane and had a remove button for Microsoft .NET Framework Assistant. Clicked it and also clicked the restart link. After the restart, the extension is still present and the remove button has gone.

This happens when you try to remove an extension which isn't installed into the users profile but system wide. We should never show the remove button in such a case. I'm sure we already have a bug on that.

Sounds like the API is saying the addon has PERM_CAN_UNINSTALL in its permissions, when it shouldn't.

Oops, I forgot to comment here. I looked at this a week ago. First I checked the code on my mac, for quite a long time, just to see that it's all fine. Then I switched to the windows box for actually testing it. Indeed I never saw the remove button for the .NET plugin, even when upgrading from a 3.6 profile. I cannot tell what fixed this, because the code in the permissions getter (which checks "locked") is as old as the new addons manager. Odd. Reporter / Henrik: Could you double check this on current trunk?

I can't reproduce it anymore. Looks like that it has been fixed by another patch already. Sebastian, if you can reproduce feel free to reopen the bug. Meanwhile I will close it as WFM.

Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100804 Minefield/4.0b3pre (.NET CLR 3.5.30729) I still see the 'Remove' button present. After clicking it, the Microsoft .NET add-on is immediately removed from the list. After restarting, it is back, but now with "0.0.0" as version number.

(In reply to comment #5) > I still see the 'Remove' button present. After clicking it, the Microsoft .NET > add-on is immediately removed from the list. After restarting, it is back, but > now with "0.0.0" as version number. With a fresh profile? If not please try to find the STR for a new profile. I don't see the problem with the restart button.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100701 Lightning/1.1a1pre SeaMonkey/2.1a3pre - Build ID: 20100701101320 Windows-only? Regression? Here, none of the app-global addons has a [ Remove ] button, and in SeaMonkey there are quite a number of them: ChatZilla

...(sorry, hit "Save Changes" too fast -- or maybe tab-space) DOM Inspector JavaScript Debugger SeaMonkey Debug & QA UI SeaMonkey Defaut Theme SeaMonkey Modern Theme

I don't see this when creating a new profile. Maybe Microsoft only updates the profiles linked in the profiles.ini?

It was probably broken on our side at some point in the development cycle, and that broke your profile - in which case I think there's nothing we should do here. I'll leave the decision to Dave.

I think I know what is going on here. At one point the Microsoft .NET extension existed globally and would install a local version into the profile. What you were seeing is probably being able to uninstall the profile version and then after the restart the global version (which has the same ID) became visible. This is rather sucky from a UI perspective, but it is nothing new, the old manager did this too. If you still have a profile that shows the remove button for this add-on can you attach the extensions.sqlite to this bug report, that would let us confirm that it is indeed a profile version masking the global version.

That confirms it, the database shows a "Microsoft .NET Framework Assistant" installed in the windows registry with version "0.0.0" and another one installed in the profile with version "1.1". Removing the profile one would reveal the registry one in the way you described in comment 0 and comment 5.

Hmm, I wonder if there's any way we can improve the experience here. We could potentially disallow removing any profile-installed extension if removing it would just result in the globally-installed extension being activated. Boris: Any ideas?

(In reply to comment #16) > Hmm, I wonder if there's any way we can improve the experience here. We could > potentially disallow removing any profile-installed extension if removing it > would just result in the globally-installed extension being activated. > > Boris: Any ideas? If two copies of a single extension are installed, one profile-local and the other app-global, then IMO there _must_ be a way to remove the profile-local copy (which always takes precedence) once the app (and the global extension packaged with it) have been upgraded to a more recent version. This applies e.g. to ChatZilla, Venkman and Dom Inspector (packaged with SeaMonkey but also available at AMO, sometimes as a more recent version). OTOH, if there is only a single copy of an extension installed app-global, it already hasn't got any Remove button AFAIK.

(In reply to comment #15) > That confirms it, the database shows a "Microsoft .NET Framework Assistant" > installed in the windows registry with version "0.0.0" and another one Dave, can't we detect the version number of the .NET framework assistant, or why do we show it as 0.0.0? There isn't a bug about it yet, right?

(In reply to comment #18) > (In reply to comment #15) > > That confirms it, the database shows a "Microsoft .NET Framework Assistant" > > installed in the windows registry with version "0.0.0" and another one > > Dave, can't we detect the version number of the .NET framework assistant, or > why do we show it as 0.0.0? There isn't a bug about it yet, right? The .NET framework assistant extension in the registry is version "0.0.0". That is no bug, the .NET team would need to change it if they wanted something different.

Thanks Dave!(In reply to comment #16) > Hmm, I wonder if there's any way we can improve the experience here. We could > potentially disallow removing any profile-installed extension if removing it > would just result in the globally-installed extension being activated. We can't disallow that. We can only hide the option in our UI, but users can still remove the extension manually from the file system. I have to second Tony's comment that it should be possible to uninstall those extensions.

(In reply to comment #20) > We can't disallow that. We can only hide the option in our UI, but users can > still remove the extension manually from the file system. I have to second > Tony's comment that it should be possible to uninstall those extensions. It didn't mean disallow completely, just not offer the option in the UI, since in nearly all cases it's not going to result in the expected behaviour. > If two copies of a single extension are installed, one profile-local and the > other app-global, then IMO there _must_ be a way to remove the profile-local > copy (which always takes precedence) once the app (and the global extension > packaged with it) have been upgraded to a more recent version. This applies > e.g. to ChatZilla, Venkman and Dom Inspector (packaged with SeaMonkey but also > available at AMO, sometimes as a more recent version). OTOH, if there is only a > single copy of an extension installed app-global, it already hasn't got any > Remove button AFAIK. This seems like a separate problem to me (although made worse by my suggestion). Ideally, you shouldn't have to micro-manage different copies of extensions like that. Two possible solutions: * Use the copy with the highest version number. That precludes the possibility of purposefully downgrading a globally installed extensions with a profile-install. * When removing the profile-installed copy, automatically disable the globally-installed copy. Doesn't fix the whole problem, but does take away a lot of the surprise.

In reply to comment #21: I've had the case in the past (with the previous avatar of the addons manager) of ChatZilla or DOM Inspector getting an "auto-update" by way of a newer copy being installed in the profile _in addition_ to the copy shipped together with SeaMonkey (and installed app-global); this was by virtue of the "automatic check for updates to extensions" as set in "Edit => Preferences => Advanced => Software Installation". I want to keep the ability to remove the profile copy once the globally shipped copy has caught up with it, _without_ losing the extension's functionalities.

Just wanted to confirm Dave's analysis - .NET Framework Assistant installs a "bootstrap" extension globally with version "0.0.0". The purpose of this bootstrap extension is to install the real extension into user's profile. To prevent user confusion Microsoft made the bootstrap extension hidden (which made tracking down issues related to it a whole lot more "fun" - https://adblockplus.org/blog/the-return-of-net-framework-assistant). The hidden flag is no longer supported which causes the current poor UI experience. Note that bug 474289 was filed to resolve just that poor UI experience by making multiple installations unnecessary.

Dave, could Microsoft modify their bootstrap extension so it get installed like a distribution bundle?

(In reply to comment #24) > Dave, could Microsoft modify their bootstrap extension so it get installed like > a distribution bundle? Not easily no, but this is something we should talk to Microsoft about separately (and have done in fact).

(In reply to comment #25) > (In reply to comment #24) > > Dave, could Microsoft modify their bootstrap extension so it get installed like > > a distribution bundle? > > Not easily no, but this is something we should talk to Microsoft about > separately (and have done in fact). As talked on IRC and proposed by beltzner, Kev can you get in contact with MS regarding this problem? Looks like they have to find a finally working solution. Thanks.

Shaver's got the contacts here, not me, so I'll redirect to him. I am not convinced that third party sw that installs into the appdir is better, however, and wonder if going the route outlined in comment #24 is the way to go. does it make sense (mid-long term) to look into offering an install mechanism for third-party extensions that go through XPinstall without having to drop an XPI or expanded extension under the appdir? The problem isn't unique to MS.

(In reply to Blair McBride (:Unfocused) from comment #21) > Two possible solutions: > * Use the copy with the highest version number. That precludes the > possibility of purposefully downgrading a globally installed extensions with > a profile-install. I disagree. User should have the option to downgrade per profile. > * When removing the profile-installed copy, automatically disable the > globally-installed copy. Doesn't fix the whole problem, but does take away a > lot of the surprise. 3. possible solution: When remove button is pressed if there is an invisible global installed, user should be warned and offered an abort option. Anyway: There should be some indication in Add-ons Manager, where an addon is installed.