733547 - [d2c] We need an "isD2C" API on AMO

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect, P1)

Description

[Gregory Koberger (:gkoberger)]

We need a way to easily check if an add-on is D2C. There are two components to this, backend and frontend. Backend is completely user agnostic, while the frontend stuff is based on the user's browser.

FRONT END
 - The user is on Firefox 10+
 - The user doesn’t have "extensions.strictCompatibility" set to "true" *
 - (Partially front) It hasn't been condemned to our D2C Blacklist (we need to match up ranges with the user's Fx version)

BACK END
 - The add-on is actually an extension (not a theme, dictionary, language pack, app, etc)
 - It has a minVersion of 4.0 or greater **
 - It doesn't have any binary components (as specified in the chrome.manifest by using binary-components)
 - It isn't explicitly marked by the author as opting out of D2C
 - (Partially back) It hasn't been condemned to our D2C Blacklist

* We don't care about this right now.
** The minVersion only has to be 2.0 if the supported application is set to toolkit in its install.rdf, but this isn’t worth supporting.

We want to make sure all the work is done in one location, so that we aren't reimplementing this every time we need to know if an add-on is D2C. I know you guys know this, but I figured I'd make it a separate bug anyway.

Comment 1

[Rob Hudson [:robhudson]]

I'm not sure `addon.is_d2c` is going to work since, e.g., version "1.1.5" of an add-on could contain binary components, which they then remove in version "1.2.0".

Unless we only report `is_d2c` for the most recent version?

But in general I like this plan. The blacklist is definitely the part that makes the logic ugly by being a range that depends on both the add-on versions and app versions.

Comment 2

[Wil Clouser [:clouserw]]

hanging is_d2c off the add-on model doesn't work for different versions of the add-on if they are compatible with different apps and aren't kept in sync.  I guess go with most recent version though unless gkoberger has other plans.

Comment 3

[Gregory Koberger (:gkoberger)]

Whoops, Rob and I talked about this in IRC -- I should have posted here.

The "is_d2c" will have to be in two parts.

The first will be version.is_d2c, which will check the basic things like binary, minVersion, add-on type, etc.

The second part will have to be done in JS, and will be the hard part -- it will check Firefox version (10+) and blacklist (since it's two ranges that require knowing the user's version of Firefox).

This is a complete oversimplification of things, and if anyone thinks of any issues we can figure it out.

Comment 4

[Christopher Van Wiemeersch [:cvan]]

(In reply to Gregory Koberger (:gkoberger) from comment #0)
>  - It has a minVersion of 4.0 or greater **

Shouldn't this be has a maxVersion of 4.0 or greater?

If I have an add-on version compatible with Firefox 3 through 8, its maxVersion (8) > 4.0 and should therefore be eligible for D2C - yes?

Comment 5

[Gregory Koberger (:gkoberger)]

cvan -- Good catch. It should be "maxVersion" rather than "minVersion". I told Rob.

Comment 6

[Rob Hudson [:robhudson]]

https://github.com/mozilla/zamboni/commit/833a65d

Comment 7

[Cristian Boldan]

Verified as fixed in FF11 with an add-on with minVersion 3.0 and maxVersion 5.0.
Postfix screencast http://screencast.com/t/34BComOL
Attaching the add-on used.
Closing bug.

Comment 8

[Cristian Boldan]

Attachment: d2c add-on

Comment 9

[Rob Hudson [:robhudson]]

Hmm. There shouldn't be a "null" in that popup. It should explain that the reason this add-on is not compatible is because it hasn't been updated (or something along those lines).

I'm thinking it is because of the unreviewed status of this add-on, which I didn't check the edge case of.

Re-opening...

Comment 10

[Rob Hudson [:robhudson]]

Closing this since it's on AMO, and other bugs have been filed.