Closed
Bug 277222
Opened 20 years ago
Closed 19 years ago
Add current Firefox version info to the "could not be installed" version incompatible message
Categories
(Toolkit :: Add-ons Manager, enhancement)
Tracking
()
VERIFIED
FIXED
People
(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)
References
Details
Attachments
(1 file, 3 obsolete files)
4.83 KB,
patch
|
Details | Diff | Splinter Review |
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."
Assignee | ||
Comment 1•20 years ago
|
||
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.
Flags: blocking-aviary1.1?
Assignee | ||
Comment 2•19 years ago
|
||
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.
Attachment #176020 -
Flags: review?(benjamin)
Comment 3•19 years ago
|
||
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.
Attachment #176020 -
Flags: review?(benjamin) → review-
Assignee | ||
Comment 4•19 years ago
|
||
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
Attachment #176077 -
Flags: review?(benjamin)
Assignee | ||
Updated•19 years ago
|
Attachment #176020 -
Attachment is obsolete: true
Assignee | ||
Comment 5•19 years ago
|
||
I just noticed that the #expand has been added so perhaps it would be more appropriate to use that here as well?
Comment 6•19 years ago
|
||
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.
Attachment #176077 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 7•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Assignee: bugs → moz_bugzilla
Attachment #176077 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•19 years ago
|
||
Ok, I realized I should have just implemented it as you noted and this patch does so. Thanks for your help with this Benjamin!
Attachment #176309 -
Attachment is obsolete: true
Assignee | ||
Comment 9•19 years ago
|
||
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
Attachment #176312 -
Flags: review?(benjamin)
Comment 10•19 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Updated•19 years ago
|
Attachment #176312 -
Flags: review?(benjamin)
Comment 12•19 years ago
|
||
(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+
Assignee | ||
Comment 13•19 years ago
|
||
*** Bug 281345 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•