Incompatible extensions are returning in Get Add-ons results window

VERIFIED FIXED in 3.4.2

Status

P2
normal
VERIFIED FIXED
11 years ago
3 years ago

People

(Reporter: tchung, Assigned: laura)

Tracking

Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Details

(Whiteboard: [server side only][ETA 5/8])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre

I found an incompatible extension that gets returned in the AMO Manager search.  This shouldnt be there, if its not compatible with my current version. 

Extension:  draugiem.iv ext

I'm unsure, but If this is a dupe of 396129, please resolve accordingly.

Reproducible: Always

Steps to Reproduce:
1. Install nightly, open addons manager
2. search for "draugiem" in search box of Get Addons
3. Click install
4. Verify "Incompatible Extension" dialog pops down.  However, hitting OK, will mark the extension as "Install Complete" in the results window.

** See screenshot
Actual Results:  
Incompatible extensions should not be returned in results

Expected Results:  
Incompatible extensions returned in results
(Reporter)

Comment 1

11 years ago
Created attachment 300896 [details]
Incompatible Extension screenshot
(Reporter)

Updated

11 years ago
Depends on: 404027
Flags: blocking-firefox3?
Priority: -- → P2
(Reporter)

Updated

11 years ago
Depends on: 404024
No longer depends on: 404027
Blocks: 404024
No longer depends on: 404024
This is an issue with the AMO API results. The result for a search for draugiem claims that the extension is compatible up to 3.0b3pre:

https://services.addons.mozilla.org/en-US/firefox/api/search/draugiem

However note that the version claimed by the api is 0.7.9.8 yet the given install link is 0.7.9.5. When that is downloaded the update check proceeds and finds that the extension is only compatible to 3.0a8:

https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id={a9972399-372c-4e56-9dbe-8f5af339ef43}&version=0.7.9.5&maxAppVersion=3.0a8&status=userEnabled,incompatible&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=3.0b3pre&appOS=Darwin&appABI=x86-gcc3&locale=en-US
Component: Extension/Theme Manager → API
Product: Firefox → addons.mozilla.org
QA Contact: extension.manager → api
Version: unspecified → 3.2
Summary: AMO Manager: incompatible extensions are returning in Get Addons results window → Incompatible extensions are returning in Get Add-ons results window
Flags: blocking-firefox3? → blocking-firefox3+
(Assignee)

Comment 3

11 years ago
This might be a dupe, checking
Status: NEW → ASSIGNED
Target Milestone: --- → 3.3
(Assignee)

Comment 4

11 years ago
I can't reproduce.

What I see at
https://services.addons.mozilla.org/en-US/firefox/api/search/draugiem
is version
<version>0.7.9.8</version>
and install link as below: 
<install hash="sha1:14d261e9edb9a06bdac44a07925af9b3ad45764d">
https://addons.mozilla.org/downloads/file/23205/draugiem.lv_ext-0.7.9.8-fx.xpi
</install>

Can you please double check your results?

This has indeed changed for this case, I wonder if it is fixed or whether something about this addon changed. Did 0.7.9.8 of that addon come out of the sandbox or something in the past few days?
(Assignee)

Comment 6

11 years ago
Updated 31st Jan.  Previous public version was 0.7.9.5.
That's a good few days before I saw this. I guess we need to find another add-on that is exhibiting the same problem. Tony did you remember any others in particular that did this?
I've yet to manage to reproduce this again, Tony any chance you could give this a try?
Keywords: qawanted
Created attachment 304979 [details]
example of faulty result

This definately seems an issue with the information returned from AMO. This is the current API result for an add-on called Taboo (https://services.addons.mozilla.org/en-US/firefox/api/addon/5756). This extension has a currently public version 0.1.1 which is compatible with 2.0b1-3.0a9. The xml shows the install xpi as 0.1.1 however the version is 0.1.2 and shows compatibility with 2.0b1-3.0b3 which is the newest version of Taboo that is still awaiting review to go public.
Keywords: qawanted
Assignee: nobody → laura
Status: ASSIGNED → NEW
(Assignee)

Comment 10

11 years ago
Search and addon should by default return the latest public version of an addon.

Will add another parameter that allows to ask for most recent version including sandboxed versions.
(Reporter)

Comment 11

11 years ago
Found another incompatible extension that appears on addons manager, but not on the released version of AMO.   Probably sandboxed again.

Adblock Plus Filter Uploader.
(Assignee)

Updated

11 years ago
Target Milestone: 3.3 → 3.4.2
Whiteboard: [server side only][ETA 4/30]
Whiteboard: [server side only][ETA 4/30] → [server side only][ETA 5/8]
(Assignee)

Comment 12

11 years ago
Created attachment 319792 [details] [diff] [review]
Patch to ensure reported version matches file version

The problem here is that the reported <version> is in the sandbox and the file linked is the last public version.  This patch fixes this.  I think we need to rework some of the version stuff for bug 430733 so I might tidy this up a little after that is done.  Works for now.
Attachment #319792 - Flags: review?(fwenzel)
(Assignee)

Updated

11 years ago
Attachment #319792 - Flags: review?(fwenzel) → review?(clouserw)
(Assignee)

Comment 13

11 years ago
Created attachment 319793 [details] [diff] [review]
Updated patch, sorry.

Sorry, in addition I'm only pulling public addons.

Also, this doesn't *completely* fix this, but it will fix the client problem.  We need to change the model for Versions to fix it completely.  

Now you'll get the most recent public version of an addon with correct compatibility information, not necessarily the most recent compatible version.  The client will filter the incompatible ones, so no install problem for the end user.  When we can do app version -> addon version accounting as in bug 430733 then we can pull the latest compatible version that matches your app version.  Confusing?  Yes.
Attachment #319792 - Attachment is obsolete: true
Attachment #319793 - Flags: review?(clouserw)
Attachment #319792 - Flags: review?(clouserw)
(Assignee)

Comment 14

11 years ago
See bug 419057 for the other bits.
Comment on attachment 319793 [details] [diff] [review]
Updated patch, sorry.

This patch would mean experimental add-ons would no longer show up in the API.  Is there a good reason for that?  I'd rather see them available, not for Firefox, but for anything else consuming the API.
(Reporter)

Updated

11 years ago
Duplicate of this bug: 433009
(Assignee)

Comment 17

11 years ago
From discussions around this big I believe the default behavior should be only to pull public add-ons, since we don't ask people to log in through the API, so this is consistent with AMO.

I'll add an optional parameter to allow pulling sandboxes ones as well - I figure this way people will only ask for it if they know what they are getting into.
(In reply to comment #17)
> From discussions around this big I believe the default behavior should be only
> to pull public add-ons, since we don't ask people to log in through the API, so
> this is consistent with AMO.
> 
> I'll add an optional parameter to allow pulling sandboxes ones as well - I
> figure this way people will only ask for it if they know what they are getting
> into.
> 

Seems like the default should show everything and options should narrow it down. I'm not thinking about the Firefox add-on browser, I'm thinking of any other application/site consuming the API.  We don't ask people to log in to view details.
(In reply to comment #18)
> (In reply to comment #17)
> > From discussions around this big I believe the default behavior should be only
> > to pull public add-ons, since we don't ask people to log in through the API, so
> > this is consistent with AMO.
> > 
> > I'll add an optional parameter to allow pulling sandboxes ones as well - I
> > figure this way people will only ask for it if they know what they are getting
> > into.
> > 
> 
> Seems like the default should show everything and options should narrow it
> down. I'm not thinking about the Firefox add-on browser, I'm thinking of any
> other application/site consuming the API.  We don't ask people to log in to
> view details.

Well the issue with this bug I think is what to return when there is both a public and then a newer sandboxed version of the same add-on. You either have to return just the sandbox version, or just the public version, or maybe both, though that seems a little weird.
Just to add I think the sensible way to go as default is to return public and sandboxed results, but where an extension has both return the public info. Not even sure if that bit should be changable.
I think there should be some way to know whether there is a new sandboxed version of an add-on in the API, whether it's complete info or just a flag.  

Regardless, my comment was regarding the patch which prevents sandboxed add-ons from showing up in the API altogether.
(Assignee)

Comment 22

11 years ago
We discussed this at length in Friday's triage.  The conclusion was that in order for the Addons mgr to work as expected, we would return only public addons. I've also opened bug 433361 to cover adding a parameter to retrieve sandboxed addons as well.
(Assignee)

Comment 23

11 years ago
Committed in r13028.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: push-needed
Resolution: --- → FIXED
Did Wil review the patch or not?
(Reporter)

Comment 25

11 years ago
(In reply to comment #23)
> Committed in r13028.
> 

hi laura, how and where can i test this patch?  I assume you committed this
into sandbox first
(Assignee)

Comment 26

11 years ago
Tony, at e.g. https://preview.addons.mozilla.org/en-US/firefox/api/1.1/addon/4042

You can point your addons manager at that by changing the values of extensions.getAddons.search.url and extensions.getAddons.recommended.url

(In reply to comment #24)
> Did Wil review the patch or not?
> 

I think the patch works fine, I just disagree with it only showing public add-ons.  The patch not only restricts lists of add-ons, but the actual add-on info itself.  For example, on the live site right now going to:  https://addons.mozilla.org/en-US/firefox/api/addon/5753 will give you add-on information.  After this patch lands that will say "addon not found"

In the meeting on Friday I said I'd understand if we couldn't make any changes to the client right now, but I think we should change it in the future so the default is to show all add-ons and an additional parameter restricts it to just public add-ons.

It appears bug 433361 tries to address this but it's backwards from my recommendation (default to show all).
(Assignee)

Updated

11 years ago
Blocks: 433431
(Assignee)

Comment 28

11 years ago
This fix caused a regression, see bug 433431.

It's specifically adding the condition
'Addon.status' => array(STATUS_PUBLIC)
that triggers the problem.

Reopening until resolved.
Status: RESOLVED → REOPENED
Keywords: push-needed
Resolution: FIXED → ---
(Assignee)

Comment 29

11 years ago
Regression fixed in r13083.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Keywords: push-needed
Resolution: --- → FIXED
[1] Using Minefield, with the default, production, setting of |extensions.getAddons.search.url| set to |https://services.addons.mozilla.org/%LOCALE%/%APP%/api/%API_VERSION%/search/%TERMS%/all/10/%OS%/%VERSION%|, I searched for the incompatible "Good Deeds" add-on with string "good deeds", and received the "All results are already installed or incompatible" message, followed by a link to "See all results (1)".  Clicking that link takes me to https://addons.mozilla.org/en-US/firefox/search?q=good%20deeds

[2] This time, again with Minefield, I set |extensions.getAddons.search.url| to |https://remora-trunk.php5stage.mozilla.com/%LOCALE%/%APP%/api/%API_VERSION%/search/%TERMS%/all/10/%OS%/%VERSION%|, and searched for "good deeds" again, which this time yielded "No matching add-ons".

[3] I also note that the difference between https://addons.mozilla.org/en-US/firefox/api/addon/5753 and https://preview.addons.mozilla.org/en-US/firefox/api/addon/5753 (https://remora-trunk.php5stage.mozilla.com/en-US/firefox/api/addon/5753, too) is that the latter two are missing values for their |<version/>| and |<compatible_applications>| elements (or am I on a rabbit trail there?)

Are [1]/[2] good enough to verify this bug?
(In reply to comment #30)
> Are [1]/[2] good enough to verify this bug?
> 

I don't think they are quite enough. The steps are correct however they need to be performed for an add-on that has a public version and a newer version in the sandbox. "Good Deeds" seems to just be in the sandbox right now.
(In reply to comment #31)
> (In reply to comment #30)
> > Are [1]/[2] good enough to verify this bug?
> > 
> 
> I don't think they are quite enough. The steps are correct however they need to
> be performed for an add-on that has a public version and a newer version in the
> sandbox. "Good Deeds" seems to just be in the sandbox right now.

Dunno why I didn't just do "AdBlock Plus Filter Uploader", as in comment 11; I see on https://preview.addons.mozilla.org/en-US/firefox/admin/addons?q=[4042] that its status is "pending review", and that when I follow the steps in comment 30, [2], but for this add-on, I don't see it returned as a search result.

Version 40682: 1.5 = pending review
Version 36353: 1.0.4 = public

If that's good enough, this can be verified, then, I think.
Yep, looks good to me
Status: RESOLVED → VERIFIED
Keywords: push-needed
(Assignee)

Updated

10 years ago
Attachment #319793 - Flags: review?(clouserw)
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.