554133 - Total search results returned is incorrect

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[krupa raj[:krupa]]

steps to reproduce:
1.search for "fire" in the add-ons manager
2.Notice the number of results listed in the "See all results(n)" link where n is the list of compatible add-ons
3.Go to https://preview.addons.mozilla.org/z/en-US/firefox/api/1.3/search/fire/all/10/Darwin/3.6

expected result:
Number of total results listed in the client and the API URL are the same.

actual result:
API client lists the total search results to 10

API URL lists the total search results to 120

Additional info:
We are pointing to preview.addons.mozilla.org

user agent:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

about: config settings-
http://img97.imageshack.us/i/picture15u.png/

Comment 1

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

Given by bug 417606 this should have been fixed for 3.0 but it even happens with a latest Gran Paradiso build. If the regression was not on the client side, has something been changed on AMO?

Comment 2

[Dave Townsend [:mossop]]

I think Ben has discovered the source of this problem in his work

Comment 3

[Matt]

(In reply to comment #0)

Is there a reason your STR say to go a different link than "See all results

https://addons.mozilla.org/en-US/firefox/search?q=fire

Comment 4

[Matt]

(In reply to comment #3)

***Didn't mean to post that yet***


Nevermind... Apparently that link has been changed to the link below.

https://addons.mozilla.org/en-US/firefox/search?q=fire

Comment 5

[Matt]

I don't think this regressed on windows.  All reported 10 except for between Range 2 and 3, which reported 11.  Checked the range tchung reported in bug 417606 comment 25 on windows and it did not work.

Semi recent builds for 1.9.0, 1.9.1, 1.9.2, and trunk also do not work (new add-on manager excluded because the search doesn't work yet).


Interesting results:

***TRUNK***

Range 1:

not implemented:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre
2008-01-28-04-trunk

broken - 10 results:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9b3pre) Gecko/2008012904 Minefield/3.0b3pre
2008-01-29-04-trunk

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-28+03%3A00%3A00&maxdate=2008-01-29+05%3A00%3A00&cvsroot=%2Fcvsroot


***MOZILLA-CENTRAL***

Range 2:

broken - 10 results:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0a1pre) Gecko/2008031102 Minefield/4.0a1pre
2008-03-11-02-mozilla-central

broken - 11 results:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0a1pre) Gecko/2008031402 Minefield/4.0a1pre
2008-03-14-02-mozilla-central

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-11+01%3A00%3A00&maxdate=2008-03-14+03%3A00%3A00&cvsroot=%2Fcvsroot


Range 3:

broken - 11 results:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0a1pre) Gecko/2008051303 Minefield/4.0a1pre
2008-05-13-03-mozilla-central

broken - 10 results:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1a1pre) Gecko/2008051402 Minefield/3.1a1pre
2008-05-14-02-mozilla-central

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-05-13+02%3A00%3A00&maxdate=2008-05-14+03%3A00%3A00&cvsroot=%2Fcvsroot

Comment 6

[Matt]

Linux basically has the same result except it gives 12 hits where windows gives 11.

Comment 7

[Ben Parr [:bparr]]

Attachment: xpcshell test

Depends on AddonRepository being in a JSM instead of an XPCOM component (bug 568728).

Comment 8

[Ben Parr [:bparr]]

Attachment: xpcshell test v2

Cleaned up the test (was a tad hasty submitting the previous patch).

Comment 9

[Dave Townsend [:mossop]]

Comment on attachment 451484 [details] [diff] [review]
xpcshell test v2

>diff -r 410d1314072f toolkit/mozapps/extensions/test/xpcshell/test_bug554133.js

>+/* ***** BEGIN LICENSE BLOCK *****
>+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1

>+ * ***** END LICENSE BLOCK *****
>+ */

Please use the public domain comment instead for new tests: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/xpcshell/test_install.js

>+function run_current_test() {
>+  AddonManager.getAllInstalls(function(aInstallsList) {
>+    aInstallsList.forEach(function(aInstall) {
>+      if (aInstall.state == AddonManager.STATE_AVAILABLE)
>+        aInstall.cancel();
>+    });

This isn't necessary. The repository should be ignoring installs in the AVAILABLE state.

>+
>+    if (gCurrentTest < TESTS.length) {
>+      var query = TESTS[gCurrentTest].query;
>+      var maxResults = TESTS[gCurrentTest].maxResults;
>+
>+      // This should fail because we cancel it immediately.
>+      AddonRepository.searchAddons(query, maxResults, FailCallback);
>+      AddonRepository.cancelSearch();
>+      AddonRepository.searchAddons(query, maxResults, SearchCallback);

This is tested elsewhere, don't think we need to repeat it here.

>+
>+      // Pull some results.
>+      AddonRepository.searchAddons(query, maxResults, SearchCallback);
>+      // Should be searching now and any attempt to search again should be ignored
>+      do_check_true(AddonRepository.isSearching);
>+      AddonRepository.searchAddons(query, maxResults, FailCallback);

Same again.

>+    }
>+    else
>+      server.stop(do_test_finished);
>+  });
>+}
>+
>+function run_test()
>+{
>+  // Setup for test
>+  do_test_pending();
>+  createAppInfo("[e-mail]", "XPCShell", "1", "1.9");
>+
>+  startupManager();
>+
>+  server = new nsHttpServer();
>+  server.registerDirectory("/", do_get_file("data"));
>+  server.start(4444);
>+
>+  // Point search to the test server
>+  Services.prefs.setCharPref(PREF_GETADDONS_GETSEARCHRESULTS, "http://localhost:4444/test_%TERMS%.xml");
>+
>+  do_check_neq(AddonRepository, null);
>+  gCurrentTest = 0;
>+  run_current_test();
>+}
>+

Comment 10

[Ben Parr [:bparr]]

Attachment: xpcshell test v3

Make changes requested by Dave. Still depends on AddonRepository being in a JSM instead of an XPCOM component (bug 568728).

Comment 11

[Dave Townsend [:mossop]]

Fixed by bug 568728

Comment 12

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

Dave, is there any way to verify the fix on trunk? We don't have AMO search support yet, so I wonder if I have to use API calls directly.

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #12)
> Dave, is there any way to verify the fix on trunk? We don't have AMO search
> support yet, so I wonder if I have to use API calls directly.

No this is not in use on trunk at the moment.

Comment 14

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

(In reply to comment #13)
> (In reply to comment #12)
> > Dave, is there any way to verify the fix on trunk? We don't have AMO search
> > support yet, so I wonder if I have to use API calls directly.
> 
> No this is not in use on trunk at the moment.

Anything we can verify now with remote search support in-place? When I search for "fire" in the add-ons manager I get 55 results. But using the API directly, I get 3845 results:

https://addons.mozilla.org/z/en-US/firefox/api/1.5/search/fire

Comment 15

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #14)
> When I search
> for "fire" in the add-ons manager I get 55 results. But using the API directly,
> I get 3845 results:
> 
> https://addons.mozilla.org/z/en-US/firefox/api/1.5/search/fire

We pass the OS and the application version to the API, which restricts it to only compatible addons in the results. So the API URL we use is more like this:
https://addons.mozilla.org/z/en-US/firefox/api/1.5/search/fire/all/25/winnt/4.0b8pre

See the extensions.getAddons.search.url preference in about:config for the template we use.

Comment 16

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

Thanks for the info Blair. I simply missed that. Looks good with Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101205 Firefox/4.0b8pre. Marking as verified fixed.