This bug seems to be related to bug 312715, but since it doesn't describe the exact same problem, I filed a new one. If one uses the Extension manager to search for updates, and updates are found, the affected extensions get a status message resembling "There's a new version of $EXTENSION_NAME available.". Now, if the user isn't interested in updating it, but rather removing it, he'll right-click on the extension and uninstall it. At this point, it would be expected that the status of the extension changes to "$EXTENSION_NAME will be uninstalled upon next restart of Firefox", but it instead stays on the "new version available" message. Thus, the user is under the impression that the uninstall function has no effect at all. Yet, a restart of the browser does uninstall the extension. This is a rather severe usability bug, marking major, and asking for blocking the release candidates. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051020 Firefox/1.5

I wonder if this is also related to bug 310422. All these bugs have to do with the description not being updated when it should have been.

It seems to perform the last chosen action. When I click "Uninstall" (the text doesn't change indeed) followed by "Update Now", the extension will be updated, not uninstalled. When I first click "Uninstall", then change my mind and click "Update" and I get the message that the update is not compatible, the status changes to "... will be uninstalled when Firefox is restarted".

It has to do with the current code needing to choose which message to display out of several based on multiple criteria while still allowing multiple possible actions during one session and allowing the canceling of operations as well. The current incorrect display text has only recently been noticed by anyone even though it has been present for quite some time because the majority of the time people complete the current action (e.g. when it states restart they restart, when it states update they update, etc.). One thing I had to balance for 1.5 was the restriction of all operations when there is a pending operation which would have solved this issue vs. providing the flexibility to cancel / change an operation without displaying the incorrect text for the average use cases while not causing any harm to the datasources. This is one ui glitch and there are a couple more of them, it doesn't cause any harm, and this will best be addressed during a ui re-write to address this and several other issues.

The use case described by the reporter seems rather edge-y to me, and while I agree that this is a usability issue, it's not severe enough to block release.

Fixed on trunk by the checkin for bug 329045.