300116 - Extension Manager only checks for updates for the selected extension

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Zach Lipton [:zach]]

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.

Comment 1

[Zach Lipton [:zach]]

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

Comment 2

[Zach Lipton [:zach]]

Attachment: Patch to fix

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

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[Mike Connor [:mconnor]]

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 5

[Mike Connor [:mconnor]]

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

Comment 6

[Zach Lipton [:zach]]

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. 

Comment 7

[Zach Lipton [:zach]]

Attachment: Move update button to the right

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.

Comment 8

[Jaime Mitchell (use [e-mail] for email)]

See discussion in bug 297580 which was marked wontfix.

IMHO this is a dupe of that bug and should have the same resolution.

Comment 9

[Mike Connor [:mconnor]]

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?

Comment 10

[Zach Lipton [:zach]]

(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. 

Comment 11

[Robert Strong (they/them - no direct email)]

(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.

Comment 12

[Benjamin Smedberg]

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

Comment 13

[Zach Lipton [:zach]]

(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. 

Comment 14

[Zach Lipton [:zach]]

(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. 

Comment 15

[Mike Connor [:mconnor]]

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.

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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".

Comment 17

[Robert Strong (they/them - no direct email)]

(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.

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 19

[Marcia Knous [:marcia]]

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".

Comment 20

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 21

[Zach Lipton [:zach]]

Attachment: Move update button to the right and make it update all extensions

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.

Comment 22

[Brendan Eich [:brendan]]

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

Comment 23

[Zach Lipton [:zach]]

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

Comment 24

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 25

[Justin Kerk]

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

Comment 26

[Ben Goodger (use ben at mozilla dot org for email)]

http://wiki.mozilla.org/Firefox:Extension_Manager_UI

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 28

[Zach Lipton [:zach]]

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. 

Comment 29

[Robert Strong (they/them - no direct email)]

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.

Comment 30

[Tim Meader]

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.

Comment 31

[Robert Strong (they/them - no direct email)]

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

Comment 32

[Zach Lipton [:zach]]

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 33

[Robert Strong (they/them - no direct email)]

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.

Comment 34

[Robert Strong (they/them - no direct email)]

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

Comment 35

[Robert Strong (they/them - no direct email)]

Attachment: patch

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.

Comment 36

[Robert Strong (they/them - no direct email)]

Fixed on trunk

Comment 37

[Peter van der Woude [:Peter6]]

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

verified