626200 - Add-on name matching should take precedence over tag matching in search results

Status: RESOLVED WORKSFORME

(addons.mozilla.org Graveyard :: Search, defect, P3)

Description

[Nan M]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
Build Identifier: en-US; rv:1.9.2.13 Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13

A search within the addons dialog with *NS* or *NoScript* or *noscript* terms consistently brings up AdBlockPlus as the top result, above NoScript, and the AdBlockPlus result fills the default field of view.

For the novice/naive searcher, this could result in installs of ABP instead of NS, or the abandoning of the search for NoScript.

It appears to be a bug in the search terms prioritisation, because a search with *Ad Block* *ad blocking* *AdBlock Plus* consistently returns AdBlock Plus in the first result place.



Surely the algorithm for addon searching shouldn't be so crudely manipulable as to allow associated terms to take priority over the *title* of the addon?

Reproducible: Always

Steps to Reproduce:
1.Create clean new profile
2.Open Tools>Add-ons|Get Add-ons
3.Type "NoScript" into the LH "search all Add-ons" box
4.Enter the search.
Actual Results:  
AdBlock Plus is returned as the top result *and* the result fills the entire default field of view.
Scrolling down shows that NoScript is returned as the second result

Expected Results:  
NoScript should appear as the top result.

A similar result is returned in a clean profile in an XP Home install of Fx, except that NoScript is included in the field of view, even though it remains below AdBLock Plus in the return.
The return of AdBlock Plus as the primary result remains a potential confusion for naive and novice users.
Moreover, it is the novice and naive users who are most at risk from scripting exploits that NoScript defends against, most of which exploits AdBlock Plus does not provide any defence against.

Comment 1

[Giorgio Maone [:ma1]]

As far as I can see, tag matching is assigned the same priority as name matching, and alphabetic sorting does the rest.

Since Adblock Plus is tagged as "noscript" (not sure why), it appears consistently on top of NoScript among search result for the word "NoScript", either in the add-ons manager UI or in the website.

I tried also tagging NoScript as "adblock", and in fact NoScript appeared as the second result in searches for "Adblock Plus" (alphabet in this case plays in favor of correctness).

I agree this is a bug: exact add-on name matching should take precedence on anything else, otherwise things get quite confusing, or look bizarre at least.

Comment 2

[Wladimir Palant]

This tag has been added by a user after I them cleaned out the tags last time, done it again now. Are users still able to edit tags? Because I am really not looking at them regularly.

Comment 3

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

This looks like it's resolved.

Since this specific case is resolved, I'll mark it as WFM.

The issue really isn't about tags, it's some complicated formula we have that tries to assure that the right add-on shows up.  I think having the tag "NoScript" on ABP, put it in the running for results, but the actual boost was based on total downloads.

Feel free to open up similar bugs, because when there's active (and continually reproducable) issues, I can usually tweak the algo to work properly.

Wlad, thanks for removing the tag.

Comment 4

[Nan M]

The lack of an alpahetical browse "all" facility at the AMO site, as there used to be, makes it somewhat important that a user should be able to search for an addon's *name*, wouldn't you say?
What other complications you may care to use in your formula are a matter for you, of course, but if a user wants to find SillyAddon that's only had a couple of downloads a month, surely they should still be entitled to interrogate your database that directly and not have to wade through search artefacts from popularity and tags etc.

Comment 5

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

(In reply to comment #4)
> The lack of an alpahetical browse "all" facility at the AMO site, as there used
> to be, makes it somewhat important that a user should be able to search for an
> addon's *name*, wouldn't you say?
> What other complications you may care to use in your formula are a matter for
> you, of course, but if a user wants to find SillyAddon that's only had a couple
> of downloads a month, surely they should still be entitled to interrogate your
> database that directly and not have to wade through search artefacts from
> popularity and tags etc.

Like I said, feel free to file bugs if you can't find add-ons that you are looking for.  We do weight title very high, but there are instances where we get it wrong - and they can be fixed.