363877 - Add target application for [e-mail]

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Administration, defect, P5)

Description

[Alex Vincent [:WeirdAl]]

Bug 299716 aims to add a [e-mail] target application.  AMO will need to support this new target before extensions can use it in their install.rdf files.

Comment 1

[Justin Scott [:fligtar]]

If the GUID for an application specified in install.rdf is not in AMO's database, it ignores it... but as it seems there will be extensions with toolkit as the *only* application, we do need to add it so that users won't get a "Must support at least one Mozilla application to be listed" error.

The problem with making it supported is that it would appear in the ever-increasing list of applications that an extension is compatible with on the add-on's public page, which we generally don't like because it takes up precious space better used for a huge motorcycle.

So I guess my question is... how soon would you like this to happen? Can it wait until Remora? (January)

Comment 2

[Alex Vincent [:WeirdAl]]

Well, currently no extensions use the new target.  They can't until bug 299716 is fixed.  After that, I'm going to try making four extensions support the toolkit:

* JSLib
* XUL Widgets (not currently hosted via amo)
* DOM Inspector (bug 342592)
* Venkman (bug 342590)

Getting Venkman working for Toolkit is pretty important to me right now; I'm blocked on my Verbosio project there.  I can wait, but I would be uncomfortable.  The question is, early January, mid-January, late January?  :-)

Comment 3

[Justin Scott [:fligtar]]

shaver/morgamic, what do you guys think about this?

It probably wouldn't be a huge deal to run SQL to add the app as supported=1 once the patch in bug 2997166 is checked in, which will probably be before remora's launch.

Since so few apps will use it and there isn't really a logo to add, it would just be the SQL statement.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We should think about this a bit, I think; bsmedberg may also have thoughts here.

Hosting things that _only_ work in the toolkit, but not Firefox or Thunderbird, seems like a pretty edge case and one that's relatively far from the end-user aims of current AMO work.  That way lies hosting of libraries and suchlike, which I think we'd like to do in the future, but not without some more thought into how to surface it to users, and how to handle dependency resolution on the site.

I think it's definitely post-Remora, though.

Comment 5

[Alex Vincent [:WeirdAl]]

I should note for the record that I do not plan to drop support for current app targets in the four extensions I listed in comment 2.  I had considered it, but was quickly persuaded otherwise.

Comment 6

[Benjamin Smedberg]

I do not think it is important for AMO to deal with non-mozilla-app toolkit compatibility gunk. I would like it to accept [e-mail] the same way it accepts other non-Mozilla markers (flock/NVU/whatever). We can think about generalized support for "library" extensions later.

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

WONTFIX: you can list any random app you want, as long as it supports one of our known target apps.  Supporting toolkit-only packages is out of scope for us.

Comment 8

[Robert Kaiser]

Now that bug 299716 is checked in, I thought we could make e.g. the new hunspell versions of dictionary packages just state toolkit as target and have them working and listed on AMO for all apps.
With this decision, it looks like there's no simplification for devs whose add.ons work on all toolkit apps, as they still need to list Firefox, Thunderbird, SeaMonkey and Sunbird along with respective versions in their install.rdf just to make them work with AMO (even though the apps wouldn't need that).

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #7)
> WONTFIX: you can list any random app you want, as long as it supports one of
> our known target apps.  Supporting toolkit-only packages is out of scope for
> us.

I'm having trouble understanding this.  I thought saying that an extension is compatible with the toolkit means it works with *all* toolkit apps, including ours.  That's certainly what http://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility#How_Applications_Determine_Compatibility suggests to me.

Being able to use this on AMO would be a *great* help to me -- I wouldn't need to spend hours doing release archaeology (which I've had to in the past) when somebody asks me to add Sunbird, Seamonkey, etc. (apps that you do support, but whose version correspondences to Gecko versions are not well documented to my knowledge) to my install.rdf.  And the version of Leak Monitor that I upload today could be marked compatible with Sunbird, etc., when a Gecko-1.9-based release of Sunbird appears.

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

How would AMO know what that correspondence is any better?  I'm fine with re-opening it -- AMO's not my call any more, for sure -- but it seems like it'd be quite a bit of work on top of the necessary version archaeology to get the system in place, showing compat correctly, and maintained.  The version-mapping information being up to date is a pre-requisite, that is, and given that your task would be straightforward enough that I'm not sure adding the complexity to AMO is worth it.

That said, a patch that worked and had tests and stuff would probably be taken, so WONTFIX seems wrong.  Oh, how I waffle.

Comment 12

[Michael Morgan [:morgamic]]

David - I am not sure I understand your workflow, but if there's something we could do via an API or pluggable feature, we should talk about it.  The advanced search has an app/version filter, maybe we could add a text search to it to match on app or something, but not sure how that would help.  Let me know what you're thinking and/or reopen this if you'd like to move forward.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Was that comment on the correct bug?

Comment 14

[Steffen Wilberg]

Reopening because comment 12, which WONTFIXed this bug, might have posted on the wrong bug, see comment 13.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To be clear, the way I think this ought to work is:

 1. AMO's database of valid versions of the applications that it supports should have the toolkit version corresponding to each app version.  So if AMO knows that there's a Firefox version called "3.1a2", it should also know that that Firefox version corresponds to toolkit version "1.9.1a2".

 2. When AMO sees an extension that's compatible with [e-mail], it should treat it just like an extension that's compatible with all applications.  So, for example, if an extension is compatible with [e-mail] (minVersion = 1.9.1a1pre, maxversion=1.9.1.*), then it should be treated just like an extension that's compatible with Firefox (minVersion=3.1a1pre, maxVersion=3.1.0.*) and with Thunderbird (appropriate versions from database), etc., in terms of what shows up in searches, what shows up as having the "Add To Firefox" button enabled, etc.

Comment 16

[Justin Scott [:fligtar]]

This is too much of an edge case and AMO versioning is too complicated for us to consider this anymore.

Comment 17

[Colby Russell :crussell (no longer Mozilla-ing)]

I'd like to petition that this be reopened for several reasons:

1. Most of the discussion (it seems) revolved around the notion that a toolkit target application means one which _excludes_ Firefox and friends but still somehow works for, I dunno, XULRunner apps or something.  (At least that's how I interpret comment 4 and comment 7.  I'm not alone; comment 10 shows dbaron interpreted it similarly.)

That's not the case, as dbaron points out.  Specifying toolkit as the target application means you inclusively support Firefox, Thunderbird, and a bunch of other applications.  It's ambiguous whether comment 16 was written ("too much of an edge case") under the same misconception.

2. Case study: The Hide Clear List Button add-on (https://addons.mozilla.org/en-US/firefox/addon/hide-clear-list-button/) overlays the Firefox download manager.  It happens that the Firefox download manager is just the toolkit download manager.  There's been much ado about install manifests being too complicated.  There was a GSoC project a year (or two) ago under Jorge's stewardship about this.  It doesn't make any sense for the install.rdf for that add-on to even mention Firefox or any other application, and in fact, it doesn't.

Here's the clincher: AMO has since been revamped so that even if you manually adjust the numbers in the install.rdf and attempt to upload a new version, it will be rejected because "No Mozilla products listed as target applications".

This isn't the place for advocacy, but it seems to me that toolkit-supporting, application-agnostic add-ons were something that we were trying to reach for where possible, not discouraging them.

Second case study: DOM Inspector's install manifest lists six target applications.  Since DOM Inspector no longer supports anything prior to 1.9 (when the toolkit target application was introduced), it should be possible to eliminate all but one of them (the toolkit one), were it not the case that AMO makes it so cumbersome—er, impossible now, I guess—to manage any add-ons other than those where you're constantly tweaking version numbers across multiple applications.

3.(In reply to comment #1)
> The problem with making it supported is that it would appear in the
> ever-increasing list of applications that an extension is compatible with on
> the add-on's public page

I'd say that any fix that actually put toolkit in the list would be in error.  It should just affect the visibility of the existing listed products.

4. (In reply to comment #16)
> This is too much of an edge case and AMO versioning is too complicated for
> us to consider this anymore.

This should be less of an issue now, and only become less so going forward, now that toolkit version numbers match the Firefox version numbers on rapid release.

Comment 18

[Colby Russell :crussell (no longer Mozilla-ing)]

Reclassifying severity as minor, given that changes to AMO since this was last reclassified means that the "workaround where present" involves adding a bazillion (all right, ~5) target applications to the install.rdf, tweaking version numbers every time there's a bump in a version in one of those applications, manually editing the install.rdf for toolkit bumps, and re-uploading a "new" version (and therefore undergoing review again?).

Comment 19

[Kumar McMillan [:kumar]]

fwiw, we now have an automated system that validates addons for compatibility with new application releases and bumps their max versions automatically (bug 649864). No need to re-upload the install.rdf.

Comment 20

[Colby Russell :crussell (no longer Mozilla-ing)]

'cept when it's toolkit

Comment 21

[hung duong]

Attachment: Desktop.xpi

Comment 22

[Alex Vincent [:WeirdAl]]

Mr. Duong, what do you need from me?  This ticket has been dead for several years now.