277222 - Add current Firefox version info to the "could not be installed" version incompatible message

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

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

The current error message provided to users is approximately as follows:

"Extension X.X.X could not be installed because it is not compatible with this
version of Firefox.(Extension X.X.X will only work with Firefox 1.0)"

I have received several reports of pre 1.0 users thinking they are using 1.0
that there is a problem with the extension install when the problem is that they
aren't using 1.0. By adding the currently installed version of Firefox to the
message this will tell the users what the problem actually is and lessen these
type of reports. The following is just one of several possible suggestions as to
how the wording could be changed:

"Extension X.X.X could not be installed because it is not compatible with this
version of Firefox (Firefox X.X). Extension X.X.X will only work with Firefox 1.0."

Comment 1

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

Requesting blocking aviary 1.1 due to that it would be nice not to have this
extension to application versioning issue when 1.1 is released.

Comment 2

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

Attachment: patch

Perhaps something like this?
Ext X.X could not be installed because it is not compatible with Firefox X.X.
(Ext X.X will only work with Firefox versions from X.X to X.X)
and
Ext X.X could not be installed because it is not compatible Firefox X.X. (Ext
X.X will only work with Firefox X.X)

With the number of people that have reported bugs to me due to thinking they
are using Firefox 1.0 when they aren't and the extension's install.rdf
specifying a minVersion of 1.0 I think something along these lines would be
appropriate.

Comment 3

[Benjamin Smedberg]

Comment on attachment 176020 [details] [diff] [review]
patch

1) When changing the meaning of strings in a .properties file, please also
change the key, so that localizers can see the change easily.

2) The app extension version is not always the same as the app version (1.0.1
has an extension version of 1.0). I think that we should use the real app
version for display to the user.

Comment 4

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

Attachment: patch

Thanks Benjamin... I believe this addresses your comments appropriately. I used
general.useragent.vendorSub and getDefaultBranch in order to avoid showing a
user set value. Could a similar approach be used for the following?

http://lxr.mozilla.org/seamonkey/source/browser/base/content/aboutDialog.xul#61

Comment 5

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

I just noticed that the #expand has been added so perhaps it would be more
appropriate to use that here as well?

Comment 6

[Benjamin Smedberg]

Comment on attachment 176077 [details] [diff] [review]
patch

This is very close. You can combine the two pref lines into one, because the
pref service implements the root prefbranch itself:

var pref =
Components.classes["@mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);

Make a new patch with that change, and I will commit it.

Comment 7

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

Attachment: patch

This includes the change to nsIPrefBranch as noted in comment #6 except it uses
the gPref global var instead. This will return a user set value for this pref
so it can be something other than the actual version which I expect would be
rare. If this is not acceptable the previous patch uses getDefaultBranch or a
#define could be used.

Comment 8

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

Attachment: patch

Ok, I realized I should have just implemented it as you noted and this patch
does so. Thanks for your help with this Benjamin!

Comment 9

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

Comment on attachment 176312 [details] [diff] [review]
patch

Haven't seen you on irc so I am requesting approval of this patch which has the
change you requested in order to get it checked in. Thanks

Comment 10

[Benjamin Smedberg]

Fixed on trunk. The final patch was slightly different, because I used the
global gPref instead of getting the service each time, and I also sanity-checked
for missing prefs.

Comment 11

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

Verified... Thanks Benjamin!

Comment 12

[Przemyslaw Bialik]

(In reply to comment #8)
> Created an attachment (id=176312) [edit]
> patch
> 
> +incompatibleMsgSingleAppVersion=%S %S could not be installed because it is
not compatible %S %S. (%S %S will only work with %S %S)

Should be "compatible with".
Sorry for nitpicking ;)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050403
Firefox/1.0+

Comment 13

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

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