Seen on both today's trunk and branch builds. STR: 1. Install the latest version of an extension (I used FlashGot) 2. Restart 3. Install an old version of an extension (ForecastFox in my case) 4. Restart 5. Open Extension Manager 6. Select the new extension and click update, see that no updates were found 7. Select the old extension and click update, the update is found When the user clicks update, their intent is clearly to check for updates for all installed extensions, there is no reason to check for updates to only one extension at a time. Furthermore, the tooltip on the update button reads "checks for updates to your extensions," indicating that the button will check for updates to all extensions, not just the selected one.

nominating as a blocker, the user could very easily be led to believe that their extension is up to date when it in fact needs to be updated

Here's a patch that makes the update button in Extension Manager check for updates to all extensions, not just the currently selected extension.

We're not taking these kinds of things on the 1.0.x branch. This was a conscious UI decision and Ben or one of the UI gurus ought to be dealing with this decision on trunk. I'm pretty sure this is a dup of several existing bugs.

I would strongly disagree that the user is _clearly_ expecting this, given that the button is sandwiched in between two selection-specific buttons. However, the tooltip is confusing, and if no extensions are selected, the button actually does check all extensions. I think we want to preserve this selection-oriented behaviour, but I'm not sure how to expose "check for all" in a discoverable way (the current behaviour isn't really discoverable either).

Comment on attachment 188694 [details] [diff] [review] Patch to fix no matter what the button does, this is the wrong fix, since we have a context menu option on the extension to update

I agree that this shouldn't go on the 1.0.x branch, that was my mistake. What if we moved the update button over to the right of the window to clarify that it applies to all extensions? If a user really wants to check for updates only to a specific extension, they can use the context menu (I didn't realize that was there, any new patch should of course keep that working) to do that. A very small number of users will even use the Extension Manager let alone want to check for updates for only one extension, and they can use the context menu for that. The update button should be a general "deal with extensions" button that takes care of all extension updating related needs.

What do people think about this? We move the update button over to the right of the command bar so the buttons on the left are specific to the selected extension and the buttons on the right refer to extensions as a whole. The update button would check for updates to all extensions, and the context-menu command would check for updates only for the selected extension.

See discussion in bug 297580 which was marked wontfix. IMHO this is a dupe of that bug and should have the same resolution.

The problem with this is that you can't rely on users finding the context menu. Most HIGs rightly warn against this. This actually got wontfixed previously, which I agree with. Also, on non-Mac these buttons have labels, so moving isn't quite so distinct, and nudging the text link seems ugly to boot. Let's back up here, what is the user problem you're trying to solve with this? A means to manually check for all extensions? Or a perceived confusion that's caused partly by a bogus tooltip, and partly by an assumption that's pretty bogus considering the UI context?

(In reply to comment #9) > Let's back up here, what is the user problem you're trying to solve with this? The user problem is as follows. A user opens the Extension Manager and wants to see if any of his extensions need to be updated. Therefore, they click on the update button, which has a tooltip indicating that it checks for updates to all extensions. Everything about the UI creates the expectation that the button will check for updates to all extensions. They then recieve a message informing them that their extensions are up to date, which is not true. As for users needing to find the context menu, this is a non-issue to me. What user situation can you imagine that would be resolved by checking for updates to only one extension? There are already several useful features in the Extension Manager that are only accessable from the context menu. Is this a good thing? Not really, but redesigning the Extension Manager is not a good use of our time. Right now, the update button is modal; it acts in one way (a update selected extension button) when something is selected, and acts in another way (a update all extensions buttion) when something isn't selected. This is a far bigger UI issue. I consider myself a fairly competant operator and the way this "feature" currently behaves was so non-obvious to me, that I didn't realize that this wasn't some sort of an UMO bug until I actually looked at the code.

(In reply to comment #10) > Everything about the UI creates the expectation that the button will > check for updates to all extensions. Not exactly, the other buttons immediately next to the update button are specific actions to individual items just as the update button is. I do agree that there should be a better way than de-selecting all items to update all items but making the update button update all items when clicked when the actions for the buttons next to it work only on the selected item is not a good solution as I see it. There have also been requests for disabling and enabling all items at the same time. It seems to me that a common solution for being able to accomplish this as well as updating all items would be more appropriate than making the one button act on all items while the buttons next to it acted only on individual items.

We have all sorts of context-menu problems here, don't we? Can you disable/enable an extension without discovering the context menu?

(In reply to comment #11) > Not exactly, the other buttons immediately next to the update button are > specific actions to individual items just as the update button is. Ergo I thought it would be best to move the update button over to the right to make it more clear that the behavior of the update button is global, while the behavior of the uninstall and prefs buttons are selection-specific. Simply put, no user should ever have the need to check for updates to only one extension (they can always choose exactly what extensions to update in the update selection dialog), and if they really do have this need for some reason, they can use the context menu. Let's do the right thing by default, not make users work for it.

(In reply to comment #12) > We have all sorts of context-menu problems here, don't we? Can you > disable/enable an extension without discovering the context menu? Nope. We certainly do have context-menu issues here, but I would rather have rarely used options that appeal only to developers like enable/disable and check for updates to only this extension live only in the context-menu, then clutter up the Extension Manager command bar with 15 different buttons.

were it not for a tooltip, the entire argument is a straw man, and its more than a little contradictory. I don't think anyone would assume that Uninstall refers to all extensions, so why would the reasonable user would expect that the button right beside it would apply to all extensions? If you're saying that we need to move it so its obviously not part of the same group, then you're conceding that the button placement identifies it as being selection-specific, and simply saying that checking for updates for all extensions is more useful and we should do that instead. I disagree with your assertion that disabling and updating single extensions are "developer" or "power-user" functions, or that they're rarely used. Its a really useful troubleshooting tool, and users are already accustomed to checking individual extensions. Its really commonly used in #firefox, and the disable feature isn't discoverable enough, based on that user experience info, anecdotal as it is. Update all isn't well-supported via the EM, and that does need to be addressed, as does the misleading tooltip, but the original aim of the manager is to manage individual extensions, not to provide UI for general update checking, we have a Check For Updates menuitem that's even more straightforward and should be used for that.

That explains why Update never found any updates for me, even for stuff that I knew there was an update for. I agree with Zach in comment #7 -- I'd much rather see a clearly labelled "Check for Updates" button somewhere to the right, and get rid of the Update button at the bottom. Having to go back to the *Help Menu* to select "Check for Updates" to see whether any extensions have updates is pretty silly, considering that you're in the "Extensions Manager".

(In reply to comment #12) > We have all sorts of context-menu problems here, don't we? Can you > disable/enable an extension without discovering the context menu? I believe we do, another example is update is always enabled for each extension even when it is disabled. Another I introduced in that it isn't obvious that it is now possible to cancel an uninstall for an extension by selecting enable when an uninstall is pending. As for the command bar, I am not arguing with anyone that it needs work. I just would prefer a solution that takes this issue *and* the other issues into account instead of going for a quick fix for just this one issue which would more than likely need to be reworked when a more complete solution is created.

Update for Extensions is in a weird state right now. Help->Check for Updates applies to the app only. I am going to work on a robust background update solution for Extensions for DPb1 The background update check and installation process should be streamlined to make the manual "check for updates to all" less necessary as a front line UI feature.

I have been testing Firefox on Mac for some time, and I always thought that button checked for all ext and theme updates. I think we need to think about what makes sense from a user perspective - I am all in favor of making it easier for users to understand the functionality of the various buttons. Especially on the mac, but right now it isn't readily apparent that the button only checks for individual updates. As Vlad notes, I would be in favor of seeing a button that would allow me to check for updates for all extensions in the actual Ext Manager. (In reply to comment #16) > That explains why Update never found any updates for me, even for stuff that I > knew there was an update for. > > I agree with Zach in comment #7 -- I'd much rather see a clearly labelled "Check > for Updates" button somewhere to the right, and get rid of the Update button at > the bottom. Having to go back to the *Help Menu* to select "Check for Updates" > to see whether any extensions have updates is pretty silly, considering that > you're in the "Extensions Manager".

A simple solution might be to just add a "Update All" button separate from the 3 current buttons, either with a vertical bar or with some space. zach said he was against this, because it confuses things even more with two Update buttons... but I think it would be pretty clear what the "Update All" button does, and the "Update" button would be just as unclear as it was before. The "Preferences" button is in the same boat, IMO -- you're in the "Extensions Manager", and you have a "Preferences" button that looks like it applies to the entire window. I'd expect global extension preferences, not a per-extension prefs dialog.

At Josh's request, here's my patch to make the update button an update all button and mvoe it over to the right side of the UI next to the "get extensions" link.

Ben's gonna fix this for b1 it sounds like, but just for tracking (hi, cbeard) I am plus'ing for 1.1. Doesn't mean I want zach to fix it, or anything like that. Ben, if you have a better bug you're already using, please dup this against it -- otherwise take this bug (or get mconnor to take it ;-). Thanks, /be

Kicking over to Ben. I'm tired of this bug now that it's more then a personal annoyance :-)

FWIW, my gut feeling on this is that while updates to single extensions may be useful for testing or other advanced purposes, the majority of users are going to assume that checking for updates would apply to all potentially updatable things; we can "thank" Windows Update for that. People are now very used to a single action which results in a list of potential updates from which they can select all or a subset. It sounds to me that, from a UI perspective, there are two quick-and-dirty options that would be effective in reducing the confusion: 1. Update tooltips and dialog text to make it clear that the function is currently context sensitive. Right now it really does give every impression that it's checking for all updates, which would override any other expectation that may have arisen from the fact that the button is placed with a bunch of other context-sensitive buttons. - or - 2. As Zach suggests, move the update button away from the enable/diable/preferences buttons and change its underlying function so that it checks for all updates and then offers a list of potential updates from which the user can select a subset if they really want to. This is, if you're interested, my preferred option as well. :) And, of course, as Ben notes, if extension update checks become part of the standard background update check, this may all become moot as we'd live in a world where one's extensions are continually checked for up-to-dateness.

Note that fixing this will make bug 264750 much more visible.

I wouldn't consider this a "blocker"... but go ahead and land this if you want.

Before I go down the road of looking to possibly land this, I'm going to wait for bug 264750. Fixing this before we fix that is just taking a big step backwards.

This patch is much more appropriate now that a couple of the other issues such as bug 299887 and bug 262373 (patch ready to land) have been fixed and I have a patch for bug 264750 that will be ready to land soon. There is still one more issue that I think should be fixed. The installer can install several items that update will never update yet the button will always be enabled... it should only be enabled if there are items that can be updated.

mconnor, if the patch in this bug won't make it in any time soon, would it be possible to at least make two changes to the existing system? 1) provide the user some means to deselect an extension instead of holding down control while clicking on a highlighted extension, or maximizing the Extension Manager so that you can see the area below the extension list, and then clicking on the area below the listed extensions. As it is with the current EM, there appears to be no way to completely deselect all extensions other than one of these two methods. You mentioned that clicking on "Update" without any selected does indeed update them all. I was delighted to find out that it does in fact do this, but to the normal user there is currently no way to attain this "no extensions selected" which will be obvious to them. Would it be possible to make an additional click on a selected extension DESELECT the extension in the list? Make the regular click act as sort of a select toggle in essence? 2) Would it be possible to dynamically change the text of the "Update" button to say "Update All" when the user deselects all extensions? This would clear things up a lot. Again, thanks for the "deselected Update" tip though. I've been using nightly builds since the day the EM was introduced, and I'd never come across this behavior.

The patch for bug 264750 will be ready to submit after the patch in bug 296566 lands.

Thanks Rob. I'll seek review and approval for this and will deal with checkin after 264750 and 296566 land to avoid making things worse then they already are.

Comment on attachment 188738 [details] [diff] [review] Move update button to the right and make it update all extensions Zach - I'll review this but I can't approve checkins... you'll need someone like mconnor to review it as well. It is also easier when you diff from the root of your tree and the patch will need to be updated for recent changes in these files. >+ case "cmd_update_all": >+ return gExtensionsView.children.length > 0; Use spaces instead of tabs like the rest of the file >+ >+ cmd_update_all: function (aSelectedItem) >+ { >+ // check for updates for all installed extensions and themes >+ gExtensionsViewController.commands['cmd_update'](null); >+ }, Same here. I think gExtensionsViewController.commands.cmd_update(null); is cleaner. > command="cmd_uninstall"/> >- <separator class="commandBarSeparator"/> >- <button id="updateButton" >- label="&cmd.update.label;" accesskey="&cmd.update.accesskey;" tooltiptext="&cmd.update.tooltip;" >- command="cmd_update"/> >- <separator class="commandBarSeparator"/> >+ <spacer flex="1"/> The separator will ensure that there is separation between adjacent items and a spacer will not. It isn't clear why the second one should be removed. > </hbox> >- <spacer flex="1"/> >+ <spacer flex="5"/> flex="1" should be sufficient... isn't it? Also, now that there is a button on the right a separator should also be used here since the adjacent button would be right next to it if th window is sized smaller than the content. >+ command="cmd_update_all"/> >+ >+ <separator class="commandBarSeparator"/> nit: there is no need for the extra line.

*** Bug 302289 has been marked as a duplicate of this bug. ***

Zach - I am submitting an updated patch in case you don't have the time to submit one. Benjamin - Ben gave his go ahead for this in comment #27. I also fixed a Thunderbird ui glitch in that all buttons but the install button have a separator.

Fixed on trunk

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+ ID:2005072709 verified