277851 - Highlight search results

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Search, enhancement, P5)

Description

[alanjstr]

When we search for terms, we should highlight in the results the words they
searched for.  Neato.

Comment 1

[(not currently active) Ted Mielczarek]

Might as well.

Comment 2

[Ian Macfarlane]

There would need to be a separate interface to this from the find bar.

How exactly do you expect to be able to implement this? For example, just in the
major search sites you have (search for term 'foo', stripping out the rest of
the parameters)
http://www.google.com/search?q=foo
http://search.yahoo.com/search?p=foo

Google uses q=, Yahoo! uses p=. The INPUT tag in the Google/Yahoo! pages are
also named differently (q,p).

How do you expect to be able to correctly identify the search terms on every
search page on the internet? What about if it's an internal site search and the
site already provides its own highlighting?

Comment 3

[alanjstr]

Ian -

This is about the internal search on addons.mozilla.org.

Comment 4

[Paul Tomlin]

Attachment: wrap search terms in span elements, css handles highlighting

needs testing (I have no data in my setup yet) but basically should work. tried
it locally with a few random strings and some edge cases.

Comment 5

[Paul Tomlin]

Actually, I can't see anywhere that $searchStr is cleaned, may need to run
strip_tags over it first.

Comment 6

[alanjstr]

You'll need to rewrite this to use the new site with templates:
http://lxr.mozilla.org/mozilla/source/webtools/addons/search.php

Highlight based on the value(s) in q, such that search.php?q=foo highlights "foo"

Comment 7

[alanjstr]

I like what you've done, but I think we should leave cleaning the input
(multiple spaces, "and", etc) to a separate line.

Would you like this bug reassigned to you?  

Comment 8

[alanjstr]

Instead of using spans, perhaps we should use something with more semantic
meaning, like em tags.

Comment 9

[Paul Tomlin]

Attachment: less condensed, more flexible

Splits the $searchTerms handling to try to make it simpler.
Now does case-insensitive comparision and works on the title too.

I added the title since I couldn't get it to highlight my own extension, but
plenty of highlight for the guy below me. Search is likely to be done from
memory, which is likely to use something in the name.

You can give this one to me.

Comment 10

[Paul Tomlin]

Attachment: for amo/v2

Mostly handled in the template.
Cleans up the search query, which can't hurt others anyway.
Doesn't require terms to be on word boundaries. This is something we just need
to make a decision on. The SQL doesn't care about word boundaries, '%blah%',
but I suspect there will be cases where it will be less than intuitive.

Comment 11

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 199049 [details] [diff] [review]
less condensed, more flexible

UMO v2 is live.  I had a lot less to do with its development, so check with morgamic before using me for reviews.

Comment 12

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 13

[Paul Tomlin]

Reassigning to default assignee, I'm not working on AMO right now.

Comment 14

[Justin Scott [:fligtar]]

Comment on attachment 199054 [details] [diff] [review]
for amo/v2

We're no longer on v2.

Comment 15

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

This can have some nasty a11y effects as I understand it, and we'd want to be pretty darned careful that we don't add XSS vulnerability paths by splitting content where the other sanitizers don't expect.  We could perhaps ship some JS that did this on the client side...

Comment 16

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

We could utilize something like:

http://www.jquery.info/spip.php?article50

But I feel like the overhead of JS highlighting is not really worth it, most things our search engine finds are obvious matches - highlighting makes more sense in dense documents.  In our case, addons details aren't very dense.

I'd favor wontfix'ing this.

Comment 17

[Wil Clouser [:clouserw]]

Dave brings up a good point - our results aren't dense.  The results for our searches are limited to 3 lines of text which should be easy enough to scan.  -> wontfix.