Closed Bug 680845 Opened 13 years ago Closed 7 years ago

Allow adding new targetApplications through the update check

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: TheOne, Unassigned)

References

(
URL
)

Details

When trying to install the add-on in the url above in Seamonkey 2.3, I get the message that it's not compatible with that version.

Indeed, the install.rdf does not contain Seamonkey compatibility, but I added it in the developer hub.
This might be non-firefox specific, not sure.  -> 4.x
Priority: -- → P5
Target Milestone: --- → 4.x (triaged)
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110824 Firefox/9.0a1 SeaMonkey/2.6a1 ID:20110824003041

I'm using a SeaMonkey version above that extension's maxVersion, but with the Add-on Compatibility Reporter 0.8.7 enabled and (in addition to what the ACR sets) extensions.checkCompatibility.2.6a set to false. Compatibiliy override does work… at least for add-ons whose install.rdf includes an <em:targetApplication> section that SezaMonkey recognizes.

That extension is listed as "supporting SeaMonkey 2.3 to 2.3.*" but it will not install notwithstanding the version compatibility override. Examination of the install.rdf shows that it has no <em:targetApplication> section for SeaMonkey, and also not for toolkit@mozilla.org. Adding either or both of them manually (and repacking the xpi with the edited install.rdf) allows the extension to install and function, even (with compatibility override) in SeaMonkey 2.6a1. See for example http://users.skynet.be/antoine.mechelynck/other/slim_add_ons_manager-6.0-tb+fx+sm+tk.xpi for a tweaked version of the addon, which will install in SeaMonkey. Nothing was changed outside the install.rdf.
OS: Windows 7 → All
Hardware: x86_64 → All
Tony, this is not about a compatibility override in Seamonkey, but about the one on amo. In general I don't need to have a <targetApplication> for Seamonkey in my install.rdf if I host my add-on on amo. I can set the compatible applications and versions on the amo webpage in the developer hub section for my add-on. amo then overrides these parts in the install.rdf and update.rdf.
Andreas: My comment #3 is about the fact that (at least when the appVersion falls outside the compatibility range set on AMO) the extension won't install if the xpi stored at AMO lacks a suitable <targetApplication>, even if AMO says that the addon support some *other* version of the same product and even if compat override is set.

IMO: (1) any extension which AMO lists as "supporting *some* version of SeaMonkey" should be installable (with no install.rdf "doctoring") in *any* version of SeaMonkey if the appropriate extensions.checkC* is set to false (e.g. through the action of the ACR). The fact that it sometimes doesn't (in the circumstances detailed in comment #3) is an AMO bug IMHO. OTOH (2) if the ACR is not enabled, and all extensions.checkC* left at their (undefined) default, the addon should not install unless it supports the *current* version of the app. Whether that support is due to the minVersion/maxVersion in install.rdf or to AMO version-query voodoo is immaterial to me, in both cases (1) and (2) above.
IMO: (1) any extension which AMO lists as "supporting *some* version of
> SeaMonkey" should be installable (with no install.rdf "doctoring") in *any*
> version of SeaMonkey if the appropriate extensions.checkC* is set to false
> (e.g. through the action of the ACR). The fact that it sometimes doesn't (in
> the circumstances detailed in comment #3) is an AMO bug IMHO. OTOH (2) if
> the ACR is not enabled, and all extensions.checkC* left at their (undefined)
> default, the addon should not install unless it supports the *current*
> version of the app. Whether that support is due to the minVersion/maxVersion
> in install.rdf or to AMO version-query voodoo is immaterial to me, in both
> cases (1) and (2) above.

This seems like a different bug to me.
Wil, what do you think?
Let me see if I have the steps to reproduce this straight:

1) You have an add-on that does not support seamonkey in the install.rdf
2) You upload it to AMO
3) In AMO's developer hub you make the add-on compatible with seamonkey
4) You attempt to install the add-on, it downloads, pings versioncheck and then cancels the install

Is that right?

If the URL in comment 1 is what you're hitting it looks like AMO is saying the add-on is compatible with Seamonkey 2.3.  So...what's the problem?
(In reply to Wil Clouser [:clouserw] from comment #7)
> 1) You have an add-on that does not support seamonkey in the install.rdf
> 2) You upload it to AMO
> 3) In AMO's developer hub you make the add-on compatible with seamonkey
> 4) You attempt to install the add-on, it downloads, pings versioncheck and
> then cancels the install

Exactly.

> If the URL in comment 1 is what you're hitting it looks like AMO is saying
> the add-on is compatible with Seamonkey 2.3.  So...what's the problem?

Hm. Frankly, I don't know where exactly the problem is. So, if AMO says the update is compatible, then this could be a problem in Seamonkey (and therefore maybe also in Firefox/Thunderbird, cause they might share the same code handling updates) aswell?
(In reply to Wil Clouser [:clouserw] from comment #7)
> Let me see if I have the steps to reproduce this straight:
> 
> 1) You have an add-on that does not support seamonkey in the install.rdf
> 2) You upload it to AMO
> 3) In AMO's developer hub you make the add-on compatible with seamonkey
> 4) You attempt to install the add-on, it downloads, pings versioncheck and
> then cancels the install
> 
> Is that right?
> 
> If the URL in comment 1 is what you're hitting it looks like AMO is saying
> the add-on is compatible with Seamonkey 2.3.  So...what's the problem?

In my case, at step 4 I was running SeaMonkey 2.6a1 with the ACR installed and extensions.checkCompatibility.* set to false (including .2.6a and .nightly). When I clicked the install button at AMO (on a SeaMonkey page), I got a box with a blue button, saying the addon was version-incompatible and asking if I was sure I wanted to install anyway. So I clicked that blue button, and finally the add-on manager refused to install the add-on, saying it didn't support SeaMonkey. So I downloaded the xpi, had a look at the install.rdf, and that's where I noticed that there was no <em:targetApplication> for SeaMonkey.

The problem is that if I override version checking I want to be able to install any SeaMonkey extension, and take it under my own responsibility to hand-disable it if it is found to misbehave. In this case AMO said the addon supported SeaMonkey 2.3, I was running SeaMonkey 2.6 with version-override, and the extension wouldn't even install until I modified the install.rdf myself.
P.S. I'm not sure it this is an AMO bug, an ACR bug or a Toolkit bug, but it can't be a SeaMonkey-specific bug because the SeaMonkey add-on install code is unmodified Toolkit code.
(In reply to Tony Mechelynck [:tonymec] from comment #9)
> In my case, at step 4 I was running SeaMonkey 2.6a1 with the ACR installed
> and extensions.checkCompatibility.* set to false

Let's not make this bug more complex, but instead focus on the main and most important issue first. Nightly/ACR/compatibility override issues should go to follow-ups if they are not fixed through this one as a side-effect.

The main and most important issue is that an add-on that is not compatible by itself (install.rdf) with a certain SM version (say, 2.3) but declared compatible on AMO will not install. As Andreas and you already said, this might very well be a Toolkit bug if it's not an AMO bug. We should keep the ACR out of this for now, though, to not complicate things further.

BTW I agree that it can hardly be an SM-specific bug (due to the nature of shared code in this area). One way how to check that would be to find or create an AMO-hosted add-on that is not compatible with Firefox by itself (install.rdf), declare Firefox compatibility on AMO only, and then check whether it can be installed in Firefox.
AMO's influence ends at that versioncheck ping.  The URL you pasted above clearly says seamonkey 2.3 is compatible.  As far as I can tell, this isn't an AMO bug.
(In reply to Wil Clouser [:clouserw] from comment #12)
> AMO's influence ends at that versioncheck ping.  The URL you pasted above
> clearly says seamonkey 2.3 is compatible.  As far as I can tell, this isn't
> an AMO bug.

The bug is probably in either AddonUpdateChecker.jsm or XPIProvider.jsm then (both under mozilla/toolkit/mozapps). I was unable to use Venkman with them so unless someone else takes a look I'll probably have to analyze this the old way (by printing to the Error Console), e.g. starting by analyzing the aUpdates parameter of the onUpdateCheckComplete callback (if it's called; otherwise onUpdateCheckError).
Moving to add-on manager on the basis of comment #13.
Component: Public Pages → Add-ons Manager
Priority: P5 → --
Product: addons.mozilla.org → Toolkit
QA Contact: web-ui → add-ons.manager
Target Milestone: 4.x (triaged) → ---
Version: unspecified → Trunk
Firefox has never supported adding new application support via the update ping and I'm not sure there is a good reason not to support this. It's probably not the norm but I've certainly heard this complaint a couple of times before.
Severity: normal → enhancement
Summary: Compatibility override fails for Seamonkey → Allow adding new targetApplications through the update check
Seems reasonable to have the add-ons mgr check compatibility if the install.rdf doesn't specify the target application that the add-on is being installed on.
Note to self (or whoever ends up getting to this):

Seems this might only require changing the behaviour of AddonInternal.applyCompatibilityUpdate()
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.