405893 - Search should match TLDs as well as download file names

Status: VERIFIED FIXED

(Toolkit :: Downloads API, enhancement, P1)

Description

[Madhava Enros [:madhava]]

[actually nominating for wanted]

Now that we're showing the (very useful!) TLD for each download, it would be great if the DM's search would match against them.  That way if a user needs to find something, and she remembers is where she got it, the search is of use to her.

Comment 1

[Ed Lee :Mardak]

Should we only search the referrer or also the download source?

And should this only match the eTLD+1 part (probably very tricky) or the whole URI?

Or an estimate if the search matches anything in the URI skipping the first 6 characters and looking at the next 20 characters.

6 for addressing ftp:// which is probably the second most likely usecase after http:// and 20 because uhh sounds like a good number.

Comment 2

[Ed Lee :Mardak]

Referrer vs source.. potentially not too difficult to search source only if referrer is empty.

If we search both referrer and source, we might match "mirror" for source "mozilla" but the UI would only show "mozilla" for the TLD because it's the referrer.

Comment 3

[Ed Lee :Mardak]

Attachment: v1

Oh, simpler than I thought. The referrer /is/ null and not just empty ;)

SUBSTR(IFNULL(referrer, source), 7, 20)

Comment 4

[Ed Lee :Mardak]

Attachment: screenshot of v1

Match file names and referrer... and source if we don't have a referrer.

Comment 5

[Ed Lee :Mardak]

Builds on top of the bug 392097 heart transplant.

Comment 6

[Madhava Enros [:madhava]]

Comment on attachment 291529 [details]
screenshot of v1

Great!

Comment 7

[Shawn Wilsher :sdwilsh]

Comment on attachment 291528 [details] [diff] [review]
v1

What's the significance of the 7 and 20 here?  A comment in the file would be awesome, as well as an explanation in the bug.

Comment 8

[Ed Lee :Mardak]

(In reply to comment #7)
> What's the significance of the 7 and 20 here?

(In reply to comment #1)
> 6 for addressing ftp:// which is probably the second most likely usecase after
> http:// and 20 because uhh sounds like a good number.

;)

.. Too bad there isn't a strpos function to find the first slash. But even then, computing the eTLD+1 will be tricky in SQL...

Comment 9

[Shawn Wilsher :sdwilsh]

what about edge cases or other new protocols?  Someone could do something like a://...

Comment 10

[Shawn Wilsher :sdwilsh]

the other question of course is what does places do in the location bar?

Comment 11

[Ed Lee :Mardak]

Attachment: screenshot of v2 (reso)

Comment 12

[Ed Lee :Mardak]

Attachment: screenshot of v2 (local)

Comment 13

[Ed Lee :Mardak]

Attachment: v2

Create a function for use in sql that does the same thing as getDisplayHost in js.

The display column could potentially be grabbed and put in a download richlistitem if we wanted.. Would need to make sure that stays in sync with referrer though.

Comment 14

[Shawn Wilsher :sdwilsh]

Comment on attachment 293327 [details] [diff] [review]
v2

>+Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");
Please remove this line from DownloadProgressListener.js now since it's included in this file which is loaded before that one in the XUL.

r=sdwilsh

Comment 15

[Ed Lee :Mardak]

Comment on attachment 293327 [details] [diff] [review]
v2

Urgh. We can't reuse the existing createFunction because apparently the script gets cleared so XPConnect doesn't have its callback anymore.

Comment 16

[Ed Lee :Mardak]

Attachment: v2.1

Correctly remove the function instead of reusing the old one.

Comment 17

[Ed Lee :Mardak]

If someone wants to check the performance of this patch..
https://build.mozilla.org/tryserver-builds/2007-12-15_23:[e-mail]/

Things seem pretty fast for me. The common case of just loading the list is really fast because it's just doing a LIKE %% match. On my windows box, searching starts showing results immediately and on my iBook, it's definitely under a second when matching something like "org".

It's got some other patches as well.

Bug 405893 - Search should match TLDs as well as download file names
Bug 408351 - Double click download should do default action (first item in menu)
Bug 408350 - Enter/return on downloads should do the same as double click
Bug 405888 - Remove the "Information" button at the right of every download row
Bug 405886 - Remove the "Open File" button at the right of every download row
Bug 394516 - Figure out a remaining-time rounding scheme for minutes -> hours/days
Bug 406857 - Don't clear referrer when restarting downloads
Bug 395735 - Instrument the location bar auto-complete to report accuracy
Bug 406359 - Unify the logic for url bar searches and drop down items
Bug 406358 - Location bar drop down ignores frequency of visits
Bug 395739 - adaptive learning (match entered text to selected item) in url bar autocomplete
Bug 393678 - location bar autocomplete should take word boundaries in account
Bug 406422 - Globally decay adaptive input history to allow for new entries
Bug 406425 - Limit how many adaptive input history entries to track
Bug 406427 - Penalize skipped results to allow adaptive learning of shifting preferences
Bug 401316 - Open-with downloads are readonly

Comment 18

[Shawn Wilsher :sdwilsh]

Comment on attachment 293339 [details] [diff] [review]
v2.1

r=sdwilsh

Comment 19

[Ed Lee :Mardak]

Checking in toolkit/mozapps/downloads/content/DownloadProgressListener.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/DownloadProgressListener.js,v  <--  DownloadProgressListener.js
new revision: 1.34; previous revision: 1.33
done
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.117; previous revision: 1.116
done

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

https://litmus.mozilla.org/show_test.cgi?id=5050

in-litmus+

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007122004 Minefield/3.0b3pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007122004 Minefield/3.0b3pre

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122005 Minefield/3.0b3pre