302791 - Dom Inspector, Reporter, Talkback show "Updates to ext_name will be performed when app_name is updated" text after extension update

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Aaron Slunt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730 Firefox/1.0+

When performing an update, everytime, it says updates will be applied to
reporter, dom inspector, and talkback, when there are no updates. Restarting
firefox gets rid of the messages, but you can just reproduce the bug again by
doing another extension update. No install dialog comes up for these either.

Reproducible: Always

Steps to Reproduce:
1.Go to EM
2.Click "Find updates"
3.Reporter, DOM Inspector, Talkback always say updates will be applied

Comment 1

[Bastian Grupe]

The exact message is "Updates to %s will be performed when %s is updated" and is
a way to tell the user that they are bundled and no standalone extension. 

Maybe the message should be changed to indicate that more clearly?

Comment 2

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

The message will also revert back when closing and opening the Extension
Manager. It is to let you know as Bastian stated that updates to that item will
be peformed when your application is updated and an install dialog will never be
displayed for these items due to this same reason.

I suspect the message should be re-worded.

Comment 3

[Peter van der Woude [:Peter6]]

What about a text like :

"You have the latest version of %s installed"

in case there is no update and use it for both extensions and
[e-mail] ?

Who (Joe User) cares if an extension is @mozilla.org ?
I'm sure no one.

Let's treat them equal.

Comment 4

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

It isn't so much the user's that don't care that concern me, I'm concerned about
those that believe they should be able to update these items as the bug reporter
thought they could. Since these items are not checked for updates it returns for
all practical puurposes immediately and then the bug reports will be DOMi,
Reporter, Talkback appear to check for updates but never actually do since the
difference can be significant.

I think the text "Updates to ext_name will be performed when app_name is
updated" is better than "You have the latest version of ext_name installed" or
the existing "No updates were found for ext_name" messages but can probably be
improved upon. It may also be that the reporter didn't actually read the text in
its entirety since comment #0 states there are words in the message that don't
exist in the message.

Comment 5

[Aaron Slunt]

(In reply to comment #4)
> It isn't so much the user's that don't care that concern me, I'm concerned about
> those that believe they should be able to update these items as the bug reporter
> thought they could. Since these items are not checked for updates it returns for
> all practical puurposes immediately and then the bug reports will be DOMi,
> Reporter, Talkback appear to check for updates but never actually do since the
> difference can be significant.
> 

> I think the text "Updates to ext_name will be performed when app_name is
> updated" is better than "You have the latest version of ext_name installed" or
> the existing "No updates were found for ext_name" messages but can probably be
> improved upon. It may also be that the reporter didn't actually read the text in
> its entirety since comment #0 states there are words in the message that don't
> exist in the message.

Your right, I did not read the entire thing. I saw "Updates will be
performed..." and automatically assumed it meant that updates would be applied
when ff was restarted. I made this incorrect assumption as well as several
others on irc simply because we actually assumed the incorrect text that was
there, which ended up confusing us. There is only a one-word difference between
those extensions and other extensions that get updated, afaik (restarted vs.
updated). So I see my inital report is not so much a bug, but more of a
confusion issue.

Why can't it just say no updates were found and leave it at that? After all, no
updates are found for the extension, and it'd eliminate any confusion.

Comment 6

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

I considered just having it state no updates found for these items when I added
the feedback and the reasons this message was added are:
1) these items will always return this state and some of these items will be
provided as standalone extensions. A user that knows there is an update
available will see the no updates message and think that update is broken for
the item.
2) these items immediately return with the message when checking for updates
while an item that can be updated will usually take several seconds before
returning with the message. After a few times it becomes fairly obvious these
items aren't being checked which would then become a bug report about these
items not being checked or if the reporter knew these items won't be checked it
would be about the message being incorrect.

It seems that the similarity between the two messages is what caused the
confusion and it should be possible to re-word it in order to avoid this confusion.

Comment 7

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

The string for this message is:
updateAppManagedMessage=Updates to %S are performed when %S is updated.

The other update strings are:
updatingMessage=Looking for updates to %S...
updateAvailableMessage=A new version of %S (%S) is available.
updateCompatibilityMessage=A compatibility update has been applied to %S.
updateNoUpdateMessage=No updates were found for %S.
updateErrorMessage=An error occurred while trying to find updates for %S.
updateDisabledMessage=Updates are disabled for %S.
updateReadOnlyMessage=Update not supported (install location is read only).
updateNotManagedMessage=Update not supported (install location is not managed by
%S).

Other description strings are:
restartBeforeEnableMessage=%S will be enabled when %S is restarted.
restartBeforeDisableMessage=%S will be disabled when %S is restarted.
restartBeforeUninstallMessage=%S will be uninstalled when %S is restarted.
restartBeforeInstallMessage=%S will be installed when %S is restarted.
restartBeforeUpgradeMessage=%S will be upgraded when %S is restarted.
incompatibleUpdateMessage=%S is checking for a compatibility update to %S.

I believe the messages it was confused with are the restart messages.

Comment 8

[Aaron Slunt]

How about this:

"Updates for %s are available only when %s is upgraded"

But then that could make someone think that they're using an out-of-date of ff
then, couldn't it?

My other proposal is:

"Updates for %s are only available with newer versions of %s"

Rob Strong, what do you think?

Comment 9

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

I think those are not that dissimilar to the current message when comparing the
diifference with the restart message and could just as easily be confused with
the restart message. They both also imply that the app may be out of date.

Comment 10

[Aaron Slunt]

Sorry for the bugspam, but I just thought of one that seems a lot better IMO:

"Future versions of %S will contains updates to %S" 

Not sure how %S works, but to clarify, the first one is Firefox, and the second
is the extension.

Comment 11

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

I believe messages like this should first mention what is being acted on in a
what then why format.

Mike, any ideas?

Comment 12

[Reed Loden [:reed]]

I thought the current message for "DOM Inspector, Reporter, and Talkback" to be
confusing. It needs to be changed.

What's the status of this bug?

Comment 13

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

Reed - what specifically about the current message confused you?

As for status, no one is working on it and I'll ask beltzner (e.g. Mike) who
deals with ui strings to take a look.

Comment 14

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

Rob, while I totally understand your concerns in comment 6, I think that from a
task perspective, what the user needs to know is whether or not an update is
available for the given extension. For that reason, I think the best answer here
would be to reuse the same string as updateNoUpdateMessage.

<semantics style="hair-splitting">Since appManaged extensions are really more
like components that can be uninstalled than extensions, the
updateNoUpdateMessage is a valid response as no updates *are* available for that
extension (just new versions of the application which contain new versions of
that component)</semantics> :)

If we get bugs logged about how it's not actually checking for the appManaged
extensions, we can WONTFIX 'em and point back here. blame=me!

Comment 15

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

Thank you kindly Mike and I'll submit a patch shortly

Comment 16

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

Attachment: patch - no i10n impact

Comment 17

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

Comment on attachment 196198 [details] [diff] [review]
patch - no i10n impact

r=me, thanks Rob.

Comment 18

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

Checked in on trunk

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.155; previous revision: 1.154

Comment 19

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

Checked in on MOZILLA_1_8_BRANCH

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.144.2.8; previous revision: 1.144.2.7