Closed Bug 581065 Opened 10 years ago Closed 8 years ago

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

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla10

People

(Reporter: whimboo, Assigned: darktrojan)

References

Details

Attachments

(1 file, 1 obsolete file)

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: 609136
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.
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
This is now implemented in ACR, and available in the 0.9 public release. See bug 678787.
Assignee: nobody → geoff
Attached patch patch (obsolete) — Splinter Review
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.
Attached patch patch v2Splinter Review
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+
Keywords: uiwantedcheckin-needed
Whiteboard: [4b2]
https://hg.mozilla.org/mozilla-central/rev/1b935b8b5034
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Duplicate of this bug: 696596
Depends on: 700988
Depends on: 701193
Depends on: 701298
You need to log in before you can comment on or make changes to this bug.