581065 - Allow searching for incompatible add-ons if compatibility checks are disabled

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2

The remote search on AMO actually only works for compatible add-ons. I think it would be a good idea to also support incompatible add-ons if the user has compatiblity checks disabled. As Dave mentioned on IRC we should definitely have a warning in the UI which informs the user that this add-on is not compatible.

Steps:
1. Start Minefield with a fresh profile
2. Disable compatibility checks
3. Search for DOM inspector

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Given the query you can start for the API we already get incompatible add-ons back from AMO. We filter out those results depending on the compatibility status of the add-on. Given that we wouldn't need a change of the API.

Example query for feed:
https://services.addons.mozilla.org/en-US/firefox/api/1.2/search/feed/all/30/fee

We filter on:

<compatible_applications>
  <application>
    <name>Firefox</name>
    <application_id>1</application_id>
    <min_version>3.5</min_version>
    <max_version>3.6.*</max_version>
    <appID>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</appID>
  </application>
</compatible_applications>

Dave, are extensions able to participate in the decision which add-ons are shown and which not? I think it would be a sweet enhancement for the ACR.

Comment 2

[Dave Townsend [:mossop]]

(In reply to comment #1)
> Dave, are extensions able to participate in the decision which add-ons are
> shown and which not? I think it would be a sweet enhancement for the ACR.

Not easily right now I think.

Comment 5

[Jack Eidsness]

Perhaps this would be a better fit for the Add-On Compatibility Reporter add-on? That way you know you're only affecting users who know the drill and have means to be helpful.

Comment 6

[Jack Eidsness]

OH, that's what ACR is. I'm an idiot. Sorry for the double spam, but it will save someone else the trouble of pointing it out.

Comment 8

[Brian King [:kinger]]

This is now implemented in ACR, and available in the 0.9 public release. See bug 678787.

Comment 9

[Geoff Lankow (:darktrojan)]

Attachment: patch

This shows the add-ons with the standard incompatible text. I wonder if we should change the colour of the install button or something?

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Geoff Lankow (:darktrojan) from comment #9)
> I wonder if we
> should change the colour of the install button or something?

Maybe. File a followup bug, and CC shorlander. The button styles are changing (see bug 646713 comment 18), so no point in doing it before then.

Comment 11

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #10)
> (In reply to Geoff Lankow (:darktrojan) from comment #9)
> > I wonder if we
> > should change the colour of the install button or something?
> 
> Maybe. File a followup bug, and CC shorlander. The button styles are
> changing (see bug 646713 comment 18), so no point in doing it before then.

I disagree, we should get UX input here before landing. If we think we need to change the button styles then we shouldn't land without doing so (and if that means waiting till new button styles then so be it). I think it largely depends what AMO are going to do with their button styles once we have default to compatible (which perhaps makes this bug redundant anyway?)

Comment 12

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Dave Townsend (:Mossop) from comment #11)
> (In reply to Blair McBride (:Unfocused) from comment #10)
> > (In reply to Geoff Lankow (:darktrojan) from comment #9)
> > > I wonder if we
> > > should change the colour of the install button or something?
> > 
> > Maybe. File a followup bug, and CC shorlander. The button styles are
> > changing (see bug 646713 comment 18), so no point in doing it before then.
> 
> I disagree, we should get UX input here before landing.

Why not display incompatible add-on search results with the same "(incompatible)" label that we display for add-ons which are installed?  We already have a way to express incompatibility, and it seems if we can do so identically in search results as installed add-ons, we're being consistent in our messaging.  This would mean no change on the Install button.

Comment 13

[Dave Townsend [:mossop]]

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

This looks like it will allow installing add-ons that don't even list Firefox as supported, I don't think we want that. I'm also wondering how this plays with the default to compatible stuff.

Comment 14

[Geoff Lankow (:darktrojan)]

Attachment: patch v2

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #13)
> I'm also wondering how
> this plays with the default to compatible stuff.

It's something I'll need to sort out in bug 693906. The patch here is still relevant, even with compatible-by-default.

Comment 16

[Dave Townsend [:mossop]]

Comment on attachment 567910 [details] [diff] [review]
patch v2

Looks good, thanks

Comment 17

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/1b935b8b5034

Comment 18

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/1b935b8b5034