678787 - ACR should let the Add-ons Manager show incompatible search results

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Compatibility Tools, defect, P1)

Description

[Justin Scott [:fligtar]]

When the ACR is installed, searching for add-ons from the Add-ons Manager should also return add-ons compatible with previous versions of Firefox.

Comment 1

[Brian King [:kinger]]

This sounds like a job for the AOM, correct me if I am wrong. Once ACR is detected, the search API call needs to be modified.

Can detection be done by just looking for the ACR in the installed add-ons list or would you like something more explicit from us?

Comment 2

[Justin Scott [:fligtar]]

I'm saying the ACR should modify the AOM to do this. If we ever integrate ACR's functionality into Firefox, then sure, the AOM could do this. But for now, it should be a feature of the ACR.

Comment 3

[Brian King [:kinger]]

Ok makes sense, we don't want to bloat the AOM code for now.

Comment 4

[David McNamara [:mackers]]

This has been implemented in r93976.

For this to work, the ACR extension needs to bundle a custom version of the core "AddonRepository.jsm" module.

With ACR installed, the extension manager will always use our version of the module until ACR is uninstalled.

I don't see any major issues with this, but it's worth remembering for some future case in which a newer AddonRepository.jsm is to be used by the EM. We then need to copy this to the ACR extension and make the same modifications.

Comment 5

[Dave Townsend [:mossop]]

That's somewhat scary. It means whenever we make changes to AddonRepository to support new features ACR will have to update to support or things will look broken

Comment 6

[David McNamara [:mackers]]

(In reply to Dave Townsend (:Mossop) from comment #5)
> That's somewhat scary. It means whenever we make changes to AddonRepository
> to support new features ACR will have to update to support or things will
> look broken

Yes, this might be too high a maintenance overhead and not really The Right Way. Some other options:

1) Don't touch existing module and duplicate search functionality somewhere else. All AOM searches will go through our function.

2) Use the custom module for only the "searchAddons" function.

3) Update core AddonRepository with some sort of "DisableCompatibilityCheck" switch.

Comment 7

[Brian King [:kinger]]

#1 also sounds scary and #3 is out for now, so I vote for #2 if possible.

Comment 8

[David McNamara [:mackers]]

r94023 of the ACR is using the custom AddonRepository module just for searching. 

This mitigates the scariness a little, but installing the ACR "locks" the search functionality within AOM to what is bundled with the installed ACR extension.

If some future search feature lands in the AOM, it will be lost to ACR users until we update our custom AddonRepository.jsm

I don't see any way of both a) customizing the search function of AddonRepository.jsm and b) allowing future changes to the search function.

Comment 9

[Brian King [:kinger]]

Note to Henrik:

Ensure other functionality in AddonRepository.jsm is not locked or broken.

Comment 10

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

DaveT, I would appreciate any feedback from you regarding the code used to implement this feature. Do you see any problems? Is that approach reasonable?

Comment 11

[Dave Townsend [:mossop]]

(In reply to Henrik Skupin (:whimboo) from comment #10)
> DaveT, I would appreciate any feedback from you regarding the code used to
> implement this feature. Do you see any problems? Is that approach reasonable?

I predict that anytime we make a change to the results of add-on searches (such as we plan to in bug 659794 we will get a number of bugs filed by users who don't see the change because they have ACR installed.

That said I'm struggling to think of an alternative way to solve this. I guess a terribly over-complicated solution would be to have the ACR proxy the http request and modify the XML on the fly to make everything seem compatible.

Comment 12

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

So, how complicated would it be to get this fixed in Firefox core (bug 581065), so we could avoid the duplication of the AddonRepository module? As given on the mentioned bug the API returns already the incompatible results, so we would only have to stop filtering those out if the compatibility preference has been set?

Comment 13

[Dave Townsend [:mossop]]

(In reply to Henrik Skupin (:whimboo) from comment #12)
> So, how complicated would it be to get this fixed in Firefox core (bug
> 581065), so we could avoid the duplication of the AddonRepository module? As
> given on the mentioned bug the API returns already the incompatible results,
> so we would only have to stop filtering those out if the compatibility
> preference has been set?

I suspect not terribly complicated but I haven't had time to double check. What I'd like to ensure is that when the user searched the results clearly labelled which add-ons weren't compatible so the user at least know what they are getting themselves into. The UI might already do that I think so long as the isCompatible property of the returned add-ons was correct, though it's possible we may need to tweak the wording for this case.

Comment 14

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

Missed to mark this bug as verified fixed by using ACR 0.9.