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

RESOLVED FIXED in mozilla10

Status

()

Toolkit
Add-ons Manager
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: whimboo, Assigned: darktrojan)

Tracking

Trunk
mozilla10
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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
Whiteboard: [4b2]
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.
(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.
Duplicate of this bug: 569609
Duplicate of this bug: 609136

Comment 5

7 years ago
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

7 years ago
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.
Duplicate of this bug: 617360

Comment 8

7 years ago
This is now implemented in ACR, and available in the 0.9 public release. See bug 678787.
(Assignee)

Updated

7 years ago
Assignee: nobody → geoff
(Assignee)

Comment 9

7 years ago
Created attachment 567223 [details] [diff] [review]
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?
Attachment #567223 - Flags: review?(dtownsend)
(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.
(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?)
Keywords: uiwanted
(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 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.
(Assignee)

Comment 14

7 years ago
Created attachment 567910 [details] [diff] [review]
patch v2
Attachment #567223 - Attachment is obsolete: true
Attachment #567910 - Flags: review?(dtownsend)
Attachment #567223 - Flags: review?(dtownsend)
(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 on attachment 567910 [details] [diff] [review]
patch v2

Looks good, thanks
Attachment #567910 - Flags: review?(dtownsend) → review+
(Assignee)

Updated

7 years ago
Keywords: uiwanted → checkin-needed
Whiteboard: [4b2]
http://hg.mozilla.org/integration/mozilla-inbound/rev/1b935b8b5034
Keywords: checkin-needed
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/1b935b8b5034
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Duplicate of this bug: 696596
(Assignee)

Updated

7 years ago
Depends on: 701298
You need to log in before you can comment on or make changes to this bug.