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

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

This might be a dupe, checking

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?

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?

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.

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.

Found another incompatible extension that appears on addons manager, but not on the released version of AMO. Probably sandboxed again. Adblock Plus Filter Uploader.

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.

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.

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.

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.

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.

Committed in r13028.

Did Wil review the patch or not?

(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

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).

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.

Regression fixed in r13083.

[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