Closed Bug 78270 Opened 24 years ago Closed 23 years ago

Order autocomplete completion candidates by time or frequency

Categories

(SeaMonkey :: Location Bar, enhancement, P4)

Product:
SeaMonkey
Component:
Location Bar
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: jwbaker, Assigned: michael.j.lowe)

References

Details

Attachments

(1 file, 28 obsolete files)

Aucomplete hybrid sort - visit count, etc
8.90 KB, patch
bugzilla
: review+
alecf
: superreview+
Details | Diff | Splinter Review 
Please don't sort the completion candidate list alphabetically.  This is
terribly annoying.  I accidentally typed foo.com, when it should have been
foo.net, and now foo.com will be the top completion choice until it expires from
my history.  *anger*

I think, from observation, that IE sorts by the string length of the candidate
matches, and gives a boost to more recently visites matches.  That sounds pretty
good.  I'd take a simple most-frequently-visited sort, and that should be easy
to implement.  Simply most-recent sort would be fine, too.
Component: XP Apps → URL Bar
QA Contact: sairuh → claudius
*** Bug 78308 has been marked as a duplicate of this bug. ***
I agree.. hewitt and I have talked about somehow weighting the nodes with
respect to visitcount and last visit date. 

German has mentioned that he thinks this will make it harder for users to find
urls in the list because they won't understand the order, but I think that if we
get the ordering down right, then the user will almost never have to search
because the url he is looking for will almost always be near the top of the list.
(i.e. users don't need alphabetical ordering to search 6 items)
Status: NEW → ASSIGNED
*** Bug 84750 has been marked as a duplicate of this bug. ***
*** Bug 88562 has been marked as a duplicate of this bug. ***
*** Bug 80403 has been marked as a duplicate of this bug. ***
Here are my ideas on the ordering of URLs for autocompletion:

1) Manually selected (chosen via the URLBar) URLs before history (linked) URLs.

Reason: User is typing a URL explicitly; a history URL is not as likely to be
what the user is looking for.

2) For manually selected URLs: Most recently used URLs first.

Reason: Most likely to show the desired URLs.

3) For history URLs, use one of the following rules:

   a) Most recently visited URL first.

Reason: Uniformity. If history URLs are to be included, this is the simplest way
to implement them.

   b) Alphabetically. Shortest match(es) (component wise) first.

Reason: This would tend to put the entry page of each site at the top of the
list. If the list is large, do not put further matches for the same domain.
   c) The shortest match of the most recently visited site (domain) first.

Reason: This would put the entry page of the most recently visited sites at the
top of the list.

The last option would look at the domain as a whole to find the time of the last
visit, then return the shortest matching history entry for that domain.
-

The handling of history URLs is open to debate (lexical vs chronological
ordering), as is whether history URLs should be included at all. However, I
think most users would agree with both #1 and #2. (Of course, #1 is not needed
if we do not have history URLs mixed in.)
*** Bug 89876 has been marked as a duplicate of this bug. ***
*** Bug 93099 has been marked as a duplicate of this bug. ***
Some good notes from dupe bug #93099.  I kinda wish you could transfer notes
from dupe bugs, but I guess it's better uncluttered.
Two comments:
- why isn't the keyword "autocomplete" in the summary?
- I would like to see the Autocomplete feature prefer, or even add (where it 
wasn't ever typed), the hostname alone, e.g. "www.cnn.com" in addition 
to "www.cnn.com/stories/20010822/microsoftslatestgambit.htm"
  (I also requested this in http://bugzilla.mozilla.org/show_bug.cgi?id=96700 )

Bugzilla doesn't operate by just jamming everything into the summary.  The bug
is under "URL Bar" and that's good enough.
Actually, I'd have to agree with Tony Tovar... I never knew this bug existed,
because I was looking under all variants of "autocomplete".  I did stumble
across it by accident when looking in the URL bar, but I have a feeling others
might not be so lucky.  Maybe a simple change from "Order completetion
candidates..." to "Order autocomplete candidates..." would suffice.

** hears a jingle as $0.02 is added to the opinions **
Votes for changing the summary      -  2  (67%)
Votes against changing the summary  -  1  (33%)

Looks like it's being changed then.
Summary: Order completion candidates by time or frequency → Order autocomplete completion candidates by time or frequency
A good tip to find duplicate is to include the duplicate resolution in the search.

But I agree, the summary was not good. I think it is still not general enough.
This bug is about how to handle the autocomplete ordering (see: bug 88562), so
not only frequency/last visit. That's why I would suggest:

this bug : 'Sort autocompletion droplist in URL bar
bug 64662: 'Sort autocompletion droplist in E-mail address bar' (see also bug 28769)
bug 69265: 'Sort completion droplist from the URL bar history'
bug 87098: 'Delete key should delete list entry in the URL bar history'

Moreover, there are many bugs dealing with autocompletion. What do you like
about creating a tree:
Mostly to remember all the enhancements and problems that get less accessible as
the global number of bug increases
and because the current situation is not clear for many of us.

bug 42796 'autocompletion usability issues'
o bug ????? 'URL bar autocompletion usability issues'
  o bug 78270 (this one), bug 54392, bug 87336, bug 63321, bug 57932, bug 92154,
bug 81838, bug 94668  etc...
o bug ????? 'E-mail, addressbook, LDAP bar autocompletion usability issues'
  o bug 28769, bug 64662, bug 49478, bug 68874, bug 83096, bug 85327, bug 87867,
bug 93453, bug 67055 etc...
o bug ????? 'URL history bar completion usability issues'
  o bug 69265, bug 87098
o bug 65498: 'Autocomplete for Subscribe in news'
o bug 45588: '[FEATURE] autocomplete local files in the URLbar'

I could finish the list, but I don't want to waste my time if you think it is
not useful.

Finally, I think that
- bug 87162 and bug 96700 are dup of bug 78270 (this one)
- bug 77935 is a dup (this one) and its second part is fixed (autocomplete can
be disabled)


Since not many people are reading the dups (so do I) I think a summary of all
the ideas about this bug is useful.

A two key sorting of the global history can be drawn out.

a) First key: the number of elements in the URL 0:1/2/3?4=5
where 0 stands for http, https or any protocol
      1 stands for the web site www.foo.org

A splitting of the URL has been proposed:
if only 0:1/2/3?4=5 is in the global history,
0:1/
0:1/2/
0:1/2/3?
0:1/2/3?4=
0:1/2/3?4=5
items should be also in the autocompletion droplist.
Ex: if the global history contain www.mozilla.org/mozdev and
www.slashdot.org/article
Then droplist would be:
http://www.slashdot.org/
http://www.mozilla.org/
http://www.slashdot.org/article
http://www.mozilla.org/mozdev

b) Second key for the URLs or splitted URLs that have the same number of elements:
- alphabetical sorting (in second key, it could be useful)
- last visited sorting
- most frequently visited sorting
- user-typed in the location bar sorting
- weightening of some of them.

And discussions:
1) what about splitting the URL?
2) what about two key sorting?
3) what would be the second key? (user pref?)
4) targeted milestone (yes... I know, there is no discussion :-D I agree, I
won't code it)

Then enhancements that should be discussed in separate bugs depending on bug
'URL bar aucompletion usability'  :
- ARROW-RIGHT: select an item in the drop-list then complete in the URL without
loading it.
(see bug 93099 for an example)
- only display 0:1/ in the droplist if the user has not completely entered the
web site.
that way, typing a word in the location bar would only display web sites in the
drop-list.
Component 2/3 etc are accessible typing ARROW-RIGHT.
- suppress the trailing / (bug 54392)
- smart handle of www. (see bug 87336), for sites like:
www.mozilla.org
mozilla.foosite.org
IMHO, droplist should not display www. in www.mozilla.org
It could be done that way: if the user has not typed www., then automatically
drop www. in the items displayed in the droplist
- smart handle of http:// (see bug 63321 and bug 57932)
- smart handle of ftp:// (bug 92154)
- what about changing the keybinding (yes, I know... there has been a big debate
on that)
o keybinding TAB for completion instead of ARROW-RIGHT
o ARROW-DOWN for scrolling instead of TAB

I disargee with the ?4=5 scheme.  Not too many people actually fill in the
QUERY_STRING of a URL by hand, but some people might type in a CGI URL and may
not desire to see the QUERY_STRING portion.  IOW, ?4 is better.

However, I do like the idea of a user pref for sorting the URL bar.  Hell, at
this point, it could be an entire subsection of the Pref menu.  (Sorting,
division format, key to press, etc.)

Also, it may not be a good idea to "autocomplete" the www. part of a URL.  Some
sites either don't like the www. (freshmeat.net, slashdot.org) or they flat out
don't have it in their DNS server.  The current format is fine.  (Currently, it
will match entries without a www, even if you type in www.)
I think configurability here would be confusing. This would become a classic 
case of "optional since the designer cannot decide what's right". IMHO, 
Mozilla should do the most reasonable thing and be consistent with it (thus, 
no configuration).

*** Bug 96700 has been marked as a duplicate of this bug. ***
According to the discussion points in my last comment, my opinion is:

1) splitting the URLs: yes, only if ARROW-RIGHT feature is implemented
I like the pattern 3?4=5 what would enable to fill manually 5 as noticed. 
Because:
- I fill 5 quite often. 
- Typing in the URL afted 3? implies that we know the web site well and we know
we can perform query in the URL bar.
- generally, a 3? query has only one identifier, so it would be just one
ARROW-DOWN to skip 3?4= (in real world cases, there would be many 5
possibilities in the droplist so one click is not very important)
Note: if the query pattern has more than one query identifier 4=5&6=7: (ex:
searching bugs in bugzilla) 3?4 is needed (but it should be remembered in the
first key sorintg that it has more than 5 elements, let's say 6 whatever is its
complexity)

2) two key sorting: yes

3) second key: last visited site first 
except for element 5 for which I would prefer an alphanumerical sorting.
Because:
- alphanumerical sorting: only interesting for sorting from the first letter.
(thus totally pointless for element 1 sorting) and when there is a lot of
possibilities. Furthermore, it is not a click saving sorting.
- number of visit: painful if we change activity. I guess that it would happened
getting nervous to always see first a site we don't want to see.
furthermore it would give the precedence to advertisement sites.
- already typed by the user: history bar droplist is done for that purpose

Notes: 
- splitted URL should of course inherit the last visit time from the entire URL
in the global history.
- I would like to stress that if the element number key is adopted as a first
key with an URL splitting, the importance of the second key is *much* less
important.
in fact: typing moz would give me only 5 site choices:
| http://mozilla.org/                   |
| http://mozillazine.org/               |
| http://mozillaquestquest.com/         |
| http://mozilla.themes.org/            |
| http://mozilla-evangelism.bclary.com/ |
+---------------------------------------+

User pref: no ways! I completely agree with Ilya Konstantinov.

Speaking purely as a user:

There is going to have to be a user preference for sorting.

There are three systems that I can see (with two purely optional systems
(Alphabetical and Random)):

Last Visited, Most Visited, Some Combination of Both.

Now, each of these three has some claim to legitimacy. In fact, some users would
prefer Last Visited (M$ refugees), some would prefer Most Visited, and some
would prefer both. I can speak to preferring Both, but also having need of Last
Visited.

Thanks
Luc "Last Visited" French
Sorry, but I'm getting confused by all the shorthand being used to describe the 
various proposals.  Am I correct in summarizing the issues as:
1. which URLs are maintained
2. what keyboard methods are available for selecting
3. what sort order the URLs are presented in

re Item 1,
Obviously, recently used URLs need to be kept, but there also has to be some 
kind of weighting-formula for holding onto frequently-used URLs (even if a lot 
of new URLs have been accessed recently).  

re Item 2,
I would love to see a right-arrow technique that allows you to load just the 
base hostname (e.g. "www.mozilla.org") before loading the entire URL.
(FYI - if this is officially adapted as a goal of this bug, then I'm perfectly 
happy letting my own bug submission on this, 96700, be changed to a duplicate 
of this bug!)

re Item 3,
Personally, I'd be very confused if anything but alphabetical sort-order was 
used.  I think the concerns of those who want other sort-orders can be handled 
through effective design of Item 1.

0:1/
0:1/2/
up to here i like ^
0:1/2/3?
this ^ should be v
0:1/2/3
the following should not be listed v
0:1/2/3?4=
this is ok v
0:1/2/3?4=5
although i think it might make more sense to use tcsh(?) completion style where 
it completes to the first discrepancy (m#http://.*/\?#), so if i have 

0:1/2/3?4=5&6=7&8=9&A=Z&B=C&F=G
0:1/2/3?4=5&6=7&8=9&Z=A&D=E&F=G
complete to
0:1/2/3?4=5&6=7&8=9
instead of
0:1/2/3?4=5

And I do manually manipulate query strings.  although i'm not your normal user.

other comments, i visit mozdev.org and mozilla.org, but autocomplete 
currently favors mozdev.org even though i visit it less frequently (say 1 in 20 
times i type www.moz do i want dev)

Personally i think i'd prefer to favor visits over most recent, because i often 
load mozilla.org, mozilla.org, mozdev.org and then want to load mozilla.org.  
It's even possible that the most recent visit to either of them happened in a 
previous session and quite likely that i'll have no memory that i last loaded 
mozdev.org.  when i start browsing i'm much more likely to want the page i've 
been to the most.  another example is google, where i sometimes mistype and get 
a non404 junk page, i still want google 99.99% of the time even though i went 
elsewhere more recently.
My bug was that Netscape 4.x did reasonable sorting,
and Mozilla 0.9.x did NO sorting. It was a regression.
I am tired of stupid arguments. Why don't you restore
the Netscape 4.x behaviour and then continue arguing how
to sort better. For crying out loud, do you even know
what "regression" means?
regression: (excerpt from Bugzilla's manual)
The bug was fixed, but then it came back (regressed). The State was changed to
Reopened. Also, for problems outside those identified in precheckin and smoke
tests that were found in current builds that were known know to working in
previous builds. Tracking these bugs will help us to identify areas that are
fragile, prone to bustage and are good candidates for adding to smoke and
pre-checkin tests.
I can't see any regression.
*** Bug 100513 has been marked as a duplicate of this bug. ***
-> XP Apps: Autocomplete?
Depends on: 40168, 40523, 40643, 42329, 42458
Keywords: meta
QA Contact: claudius → zach
Summary: Order autocomplete completion candidates by time or frequency → autocompletion usability issues
I have no idea why Bugzilla made those changes (or, maybe it's a weird cache
problem with Mozilla). For some reason, this bug just "became" bug 42796.

Changing back:

Bugs this depends on: "40168, 40523, 40643, 42329, 42458" -> ""
Keywords: "meta" -> ""
QA Contact: "zach@zachlipton.com" -> "claudius@netscape.com"Summary:
"autocompletion usability issues" -> "Order autocomplete completion candidates
by time or frequency"
No longer depends on: 40168, 40523, 40643, 42329, 42458
Keywords: meta
QA Contact: zach → claudius
Summary: autocompletion usability issues → Order autocomplete completion candidates by time or frequency
Priority: -- → P4
Target Milestone: --- → Future
*** Bug 87162 has been marked as a duplicate of this bug. ***
*** Bug 106091 has been marked as a duplicate of this bug. ***
A minor addition - I can't tell if this is being suggested or not, but
I would like to be able to autocomplete only *part* of an URL (usually
the hostname), then type in some more, and *then* have it offer me choices
for the rest.  For example: currently if I type

 sou

into the url bar, I am given a long list of URLs which start with
"sources.redhat.com".  I would like to be able to push TAB at this point
and have Mozilla fill in the entire hostname, _but no more_, and leave me
in the URL bar to type more.  The current behavior is that TAB fills in
the entire rest of the first URL on the list, which may or may not be what
I want; and then I have to backspace over all of the unwanted component to
proceed.

Really, what I want is for autocompletion in the URL bar to work like tab
completion of filenames in Bash, but I'll settle for "complete just the
hostname first".
zack, that was comment #10, you should always read and familiarize yourself with
the entire bug report before making a comment.

autocompleting to the hostname should be dealt with as a separate enhancement -
like bug 96700.

bunching ideas/bugs into one bug report only confuses the issue and leads to
nothing being fixed.
The platform item is in error.

Side note:
As of 0.9.7, this has gotten to the point where it interferes with normal
browsing. IMHO, this should be Priority 2, Target 1.0 (I'm sorry, the current
behavior is *UNACCEPTABLE* for a non-beta browser, which 1.0 implies.)
Hardware: PC → All
I think we should just put in the sorting on a domain name basis first, and work
from there.  A bug/feature like this needs to be done carefully to make sure
that we aren't stepping on anybody's toes.

As it is, it appears to not find the biggest URL and put it first, but it still
shows longer URLs when I'm just typing in the domain.  Let's just put in the
0://1/2/3?4=5 model first and tweak it later.  BTW, bug 93099 (a dupe which had
a lot of comments before it was killed) has some good suggestions as well.
I started working on this last month, and have it so that you can set a hidden
pref, and switch between different sorting methods (since it's really just a
different comparison function for the quicksort)

I'll attach a patch in a few days.
Assignee: hewitt → alecf
Status: ASSIGNED → NEW
The attached patch sorts websites (authorities) before webpages.

A URL list will look like:

  http://slashdot.org/
  http://www.salon.com/
  http://slashdot.org/article.pl?sid=02/01/25/0336201&mode=thread
  http://www.salon.com/politics/feature/2002/01/25/enron/index_np.html

A thought, for website URLs, perhaps it should sort by hostname
rather than full URL. www.salon.com would sort before slashdot.org.

In addition the patch corrects a simple syntax error from nsGlobalHistory.h

I've read through the discussion and I was half way through
implementing an additional secondary key for last visited
when I concluded (IMHO) that it was a bad idea.
People are typing in by *spelling*, give them spelling feedback.

Anyways, I think sorting websites first is *absolutely* necessary
so that users get choice and feedback.	Otherwise a list of 20
webpage urls from one website floats to the top and they have to
either continue typing blindly or manually scroll which is the
current case.
Am I correct in that the current system doesn't distinguish between things I
type in manually into the bar and things in the regular history?

The problem I seem to run into is that thing that I type in dissappear because
they are pushed out of the history by time or by excessive surfing. I'd like
them to stay much longer. That's probably a different bug, right?
first, there are two bugs in nsGlobalHistory.{cpp,h}

 mCommentColumn is initialized out of order in the constuctor.
 this causes a syntax warning.

 AutocompleteSortComparison returns nsCRT::strcmp(s1.get(), s2.get());
 except that nsAutoString::get() returns type PRUnichar.  Is this being
 converted on the fly?

This patch is more type savvy, unicode safe, etc.
It also sorts xyz.com websites before www.xyz.com websites.

Chris
Alec: Any update on comment #34? You mentioned that a patch may be available in
a few days, but that was about a month ago :-/.
I actually lost the patch when I reinstalled my linux box. (note to others:
upgrading from RH6.0 to RH7.2 doesn't always go as smooth as one would hope :))
Chris, thanks for working on this.  There is now a way to tell if an url in
global history was typed in by the user or not.  The typed column for the row in
the db holds this information.  Do you want to try to incorporate the weighting
of this into the sort?  We need to keep AutoCompleteSortComparison speedy.  I'm
not sure of the fastest and easiest way to retrieve such information from the
callback function.
> There is now a way to tell if an url in global history was typed in
> by the user or not.  The typed column for the row in the db holds this
> information.  Do you want to try to incorporate the weighting
> of this into the sort?

I do need a code pointer.  But if it is really difficult,
we should pass and just put this thing to bed.  The current sort,
strcmp is really embarassing.

IMHO, people type in websites rather than webpages, so these are already
going to float to the top.  All we need to do is get the link into the
first six, then the user can tabScroll.  Well he could if y'all fixed
bug 131325.

<SHAMELESS_BUG_PLUG>
http://bugzilla.mozilla.org/show_bug.cgi?id=121325
</SHAMELESS_BUG_PLUG>

> We need to keep AutoCompleteSortComparison speedy.  I'm not sure of the
> fastest and easiest way to retrieve such information from the callback
> function.

I'm not too worried about speed, especially right now.  But this does
argue against too many comparisons.

Also, remember that this sorting happens *after* filtering.
The user types characters, then a filter function is run over
the url history and only surviving urls are sorted.
So when I typed g about 200 or so google searches came up,
and this is probably worst case.  There was a very slight pause
before the list popped up.

Chris
Blake: Regarding comment #40, now that bug 87970 is FIXED, does that address
your concerns about weighting the results in favor of user-typed URIs?
Regarding user typed URLs, do they have a seperate history, or are they expired
or removed from this control with the same rules as everything else? If the
latter, this is not optimal. If I go through the trouble to type in a URL, I
would like it to hang around in the list for a very long time.
This bug is annoying if you type an URL wrong and correct it after that - the
autocompletion will always use the wrong one (LRU or something would be great)
Attached patch sort results by last visit date (obsolete) — — Splinter Review 
Ok, I finally took a few minutes to hack this together. here's a patch which
sorts by last-visited date.

I also included code to get the visit count. I'm going to figure out some
formula based on these two.
What about adding weight to typed and figuring out a formula for the 3? :)
The aim of the autocomplete list is to predict what the user is typing.  Surely
the best way to do this is to order the autocomplete list by 'visit count' first
and then by 'last visit date' for sites with identical visit counts.

Using 'visit count' as the primary sort order is analogous to Google sorting
their search results by 'most popular' sites.  However, using 'last visit date'
as the primary sort order is analogous to the page forward/back button dropdown
list.  Why do the links I visited most recently belong at the top of my
autocomplete list?   If I visit www.cnn.com frequently, and then click to goto
some link from here (eg. www.cnn.com/a_story.htm), and then type in 'www.cnn.',
into the URL bar, why would I want the site's subpage listed first and not the
main page (www.cnn.com)?

I've modified Alec's patch to implement my suggested ordering and will attach it
below.  In practice this ordering seems to work quite well.

I'm also nominating this bug for mozilla1.0, since it seems the fix is close to
being complete.  It would be a shame not to fix the current broken autocomplete
ordering for 1.0!
Keywords: mozilla1.0

    
  
Keywords: patch

    
    

    
  
It seems like any of the aforementioned solutions is better than the current
behavior. Why not just get something in and change it if people find that it
receives complaints in 1.0?

    
  

        Attachment #66416 -
        Attachment is obsolete: true

    
  

        Attachment #67202 -
        Attachment is obsolete: true

    
  

        Attachment #73967 -
        Attachment is obsolete: true

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  


  
I've looked at the new visit count and last visit sort patches.
This is very different from the current behavior,
simple alphabetical sorting with strcmp().  My patch was an improvement
on strcmp() but with websites sorted before webpages.

Some things to keep in mind:

  The user is spelling something out.  Sorting doesn't even occur until *after*

  the user has typed in a letter.  The URL history is then filtered using
  that prefix, and finally sorted.  The user is thinking about spelling
  so the feedback should be alphabetically oriented.

  The user has bookmarks and history tools available
  so autocompletion doesn't have to duplicate those.
  Most recently shows up in history and most visited shows up in bookmarks.

  Sorting on date/count is precisely making use of insignificant statistics.
  Is 6 really that much better than 4?	Is yesterday morning
  really that different from yesterday afternoon?
  A distinction without a difference.

  Sorting websites first is most helpful after the first letter
  when a list of hundreds thousands is being being winnowed down.
  Having a list of websites helps jog the memory.

So any guess we provide the user, and that is what we are doing, guessing,
has to make sense and be predictable, else it will be confusing.
Don't you hate artificially intelligent software that guesses for you
but not like you?  Tivo comes to mind.	Wouldn't you prefer it was dumb
and predictable but helpful?  Predictable counts for a lot.

Anyways, I've said my piece.  Saying more would be saying less.
It is a fun problem and much respect to the other patchers.

Attached is an updated patch against 0.99

    
    

    
  
good job. as if this bug wasn't hard enough to follow as it is.

    
    

    
  
The problem with bugzilla sending progressivly larger problems is a known race
condition in the processmail code.

    
    

    
  
Chris: this bug is to "Order autocomplete completion candidates by time or
frequency".  Your patch is not related to this problem and should be attached to
a seperate bug report.  Regardless, I believe that your patch and the approach
of putting websites before webpages is not the right approach to take for
several reasons:

1. A website address is very often not the most common web page a user might
visit within a web site, so why should they always be placed first?   An example
from my own browsing : I goto www.abc.net.au/news/ daily, but very rarely goto
www.abc.net.au

2. I believe that alphabetic sorting of URLs in the autocompletion list, as per
your patch, is a terrible approach to take.  If I type in www.moz... into my URL
bar I get a huge list (~ 40) of URLs presented in the autocomplete list.   Why
would I want this list sorted alphabetically, and have to dig through a large
list to find the common sites I might visit (eg. www.mozilla.org/bonsai.html,
www.mozilla.org/releases/ , etc).   Furthermore, URLs are often meaningless (eg.
http://www.mozillazine.org/talkback/read.php?f=4&i=1454&t=1454), so sorting a
number of such meaningless URLs has no purpose.

3. Your only point against sorting by visit count is "The user has bookmarks and
history tools available so autocompletion doesn't have to duplicate those". 
This statement is spurious.  These tools might be available, but the purpose of
this bug report it to improve the autocomplete list.  To navigate to a URL I
often find it faster to type in the start of a URL (eg. www.moz..., or
www.abc... ) and have the URL bar autocomplete the rest of it, than to use the
mouse to find the corresponding bookmark.  However, for this to work effectively
the autocomplete list must be able to predict what URL I'm searching for.  The
most effective way to make such a prediction is to take my browsing history into
account, and thereby place my most frequenctly visited sites first (as per my
proposed patch).

    
    

    
  
Daniel: Re: "Why not just get something in and change it if people find that it
receives complaints in 1.0?".   I'm keen to seek r/sr's for the patch I've
attached and then check it in, but this bug is currently assigned to
alecf@netscape.com.  Unless alecf is willing to hand this bug over, we are
currently waiting for him to take the next steps.  With only a short time
remaining in the Mozilla1.0 cycle, unless something is done soon this bug is not
going to make the cut-off date.

    
    

    
  


  
First, I'm very embarassed by the multiple copies of my last entry.
I have no idea what happened.  Perhaps someone with authority
can clean this mess up.

I've appended a new patch which sorts websites (www.xyz.com) and webpaths
(www.xyz.com/path/) together followed by webpages.  This is both simpler
and addresses a problem which Michael brings up.  After 'x' a sort might be:

  http://xxx.com/
  http://xxx.com/path/
  http://xyz.com/
  http://xxx.com/path/page1.html
  http://xxx.com/path/page2.html
  http://xyz.com/path/page1.html
  http://xyz.com/path/page2.html

"Your patch is not related to this problem and should be attached to
a seperate bug report."  I see your point.  There has been some discussion
of the bug title earlier.  But I think that since your approach and mine
are in opposition, that we should address this directly regardless of
the title.  My patch is an improvement to strcmp() and yours
is a weighted date/count approach. I think we agree that strcmp()
by itself is bad.

"A website address is very often not the most common web page a user might
visit within a web site, so why should they always be placed first?"
Stability and predictability.  But I agree that websites and paths
should be considered equally and I've modified my patch accordingly.

I think this also addresses your second point, avoiding a bunch
of junk webpages being pushed to the front of the list.

For your third point, I'm less opposed to visit count, which changes slowly
than to date.  If I visit a site 100 times chances are I'm interested in it.
If I visited it yesterday morning vs yesterday afternoon this is meaningless.

I do believe, and this is subjective on my part, that the fact that
the user is spelling something out and has history and bookmarks matters
in the design of autocompletion.  Especially that the user is spelling.

Chris

    
    

    
  
adding self to cc list

    
    

    
  
Chris: (Re: comment #72) You claim that alphabetic sorting should be used since
"the user is spelling something out".  Whilst I agree that the user is spelling
something out, I don't see why it follows that the autocomplete list should be
sorted alphabetically.  Lets consider the scenarios of how I use the
autocomplete list:

1. The autocomplete list for me is a device to help complete a partial url.  If
I type in "www.moz" then if I can see the site I'm looking for in the
autocomplete list I'll choose it from the list. If not then I'll type in a few
more letters to reduce the number of entries in the autocomplete list until I
can see it.  It is faster to type in a few more letters to cull the autocomplete
list than it is to scroll though a large list looking for a particular url. 
Therefore, the sooner the site I'm looking for appears near the top of the
autocomplete list the sooner I can choose it and the fewer letters I have to
type.  This scenario implies that the autocomplete list should place the most
likely matches near the top of the list.  However, alphabetic sorting does not
do this.

2. If you turn on the "Autocomplete best match as you type" option in the smart
browsing autocomplete preferences you'll soon realise that this setting relies
on the autocomplete list being sorting by most likely matches - the most likely
match must be placed at the top of the list. However, alphabetic sorting does
not do this.

Your work-around for scenario 1 is to put web-sites and web-paths before web
pages. Whilst I agree that in general this is a valid thing to do, there are
problems with it:

1. It does not provide a solution to scenario 2 above - the most likely match
must be placed first in the autocomplete list.

2. In the case where a particular web page may be visited frequently but the
corresponding web-path or web-site is not, why put the web-site or web-path
before the web page?

However, I don't totally dismiss your approach.  I still insist that the primary
sort mechanism must be visit count, but I like your idea of giving priority to
web-sites and web-paths.  So, I've been experimenting and in my latest patch my
sorting algorithm is this:

1. For the urls being compared, extract the visit count and if the url is a
web-site or web-path, add 5 to the visit count.
2. Compare the adjusted visit counts and if they are are different then return
the comparison result, else goto step 3
3. Do an alphabetic comparison of the urls (with http://[www] and ftp://[ftp]
stripped off first) and return the result

This is obviously a hybrid of our two approaches.  The net result is that it
places frequenctly visited sites high in the list, and web-sites/web-paths
before web pages.  It meets to criteria of both the scenarios above and it seems
to work nicely in practice.  You'll also note that I'm using an alphabetic
comparison as the secondary sort criteria instead of "last visit date".  This is
because it does seem more logical to group urls from the same site together if
the user does decide to scroll through a large autocomplete list.

I'll attach a patch soon.

    
  

        Attachment #76005 -
        Attachment is obsolete: true

    
  

        Attachment #76006 -
        Attachment is obsolete: true

    
  

        Attachment #76007 -
        Attachment is obsolete: true

    
  

        Attachment #76008 -
        Attachment is obsolete: true

    
  

        Attachment #76009 -
        Attachment is obsolete: true

    
  

        Attachment #76010 -
        Attachment is obsolete: true

    
  

        Attachment #76011 -
        Attachment is obsolete: true

    
  

        Attachment #76012 -
        Attachment is obsolete: true

    
  

        Attachment #76013 -
        Attachment is obsolete: true

    
  

        Attachment #76014 -
        Attachment is obsolete: true

    
  

        Attachment #76015 -
        Attachment is obsolete: true

    
  

        Attachment #76016 -
        Attachment is obsolete: true

    
  

        Attachment #76017 -
        Attachment is obsolete: true

    
  

        Attachment #76019 -
        Attachment is obsolete: true

    
  

        Attachment #76020 -
        Attachment is obsolete: true

    
  

        Attachment #76021 -
        Attachment is obsolete: true

    
  

        Attachment #76022 -
        Attachment is obsolete: true

    
  

        Attachment #76023 -
        Attachment is obsolete: true

    
  

        Attachment #75576 -
        Attachment is obsolete: true

    
    

    
  


  
Attaching latest autocomplete sorting patch.

    
  
Keywords: nsbeta1

    
  
Keywords: review

    
  

        Attachment #76248 -
        Attachment is obsolete: true

    
    

    
  
*** Bug 67055 has been marked as a duplicate of this bug. ***

    
    

    
  
Taking this bug.
Assignee: alecf → michael.lowe

    
    

    
  


  
Attaching a new patch - nothing should have changed in the sorting algorithm,
but I've clean up the code ready for review

        Attachment #78103 -
        Attachment is obsolete: true

    
    

    
  
The latest patch, which has the support of Chris Sears also, is now waiting for
review.  Hewitt, alecf, blaker, bbaetz, anyone - care to help us out?  We would
like to get this checked into the trunk, and with the support of the drivers,
into the Mozilla 1.0 branch also.

    
  
Target Milestone: Future → mozilla1.0

    
    

    
  
Comment on attachment 78885 [details] [diff] [review]
Aucomplete hybrid sort - visit count, etc

This is out of my area to r=, so I'll just comment on the code itsself, not the
algorithm.

>Index: nsGlobalHistory.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/history/src/nsGlobalHistory.cpp,v
>retrieving revision 1.139
>diff -u -r1.139 nsGlobalHistory.cpp
>--- nsGlobalHistory.cpp	29 Mar 2002 02:45:47 -0000	1.139
>+++ nsGlobalHistory.cpp	12 Apr 2002 12:27:12 -0000

>+
>+  // Favour websites and webpaths more than webpages by boosting 
>+  // their visit count.  This assumes that URLs have been normalized, 
>+  // appending a trailing '/'.
>+  PRBool ts1 = PR_FALSE, ts2 = PR_FALSE;
>+  if (s1.Length() > 0)
>+  {
>+    ts1 = s1.Last() == PRUnichar('/');
>+    if (ts1)
>+      item1count += 5;
>+  }
>+  if (s2.Length() > 0)
>+  {
>+    ts2 = s2.Last() == PRUnichar('/');
>+    if (ts2)
>+      item2count += 5;
>+  }

Use !foo.IsEmpty() instead of |foo.Length() > 0|.

>+    if      (Substring(s1, 0, 11) == NS_LITERAL_STRING("http://www."))  o1 = 11;
>+    else if (Substring(s1, 0,  7) == NS_LITERAL_STRING("http://"))      o1 =  7;
>+    else if (Substring(s1, 0, 16) == NS_LITERAL_STRING("https://www.")) o1 = 16;
>+    else if (Substring(s1, 0, 12) == NS_LITERAL_STRING("https://"))     o1 = 12;
>+    else if (Substring(s1, 0, 10) == NS_LITERAL_STRING("ftp://ftp."))   o1 = 10;
>+    else if (Substring(s1, 0,  6) == NS_LITERAL_STRING("ftp://"))       o1 =  6;
>+
>+    if      (Substring(s2, 0, 11) == NS_LITERAL_STRING("http://www."))  o2 = 11;
>+    else if (Substring(s2, 0,  7) == NS_LITERAL_STRING("http://"))      o2 =  7;
>+    else if (Substring(s2, 0, 16) == NS_LITERAL_STRING("https://www.")) o2 = 16;
>+    else if (Substring(s2, 0, 12) == NS_LITERAL_STRING("https://"))     o2 = 12;
>+    else if (Substring(s2, 0, 10) == NS_LITERAL_STRING("ftp://ftp."))   o2 = 10;
>+    else if (Substring(s2, 0,  6) == NS_LITERAL_STRING("ftp://"))       o2 =  6;
>+

Where do these numbers come from? If its meant to be the length of the constant
part, then the
"https://" ones are both wrong.

You could possibly do:

const char httpWWWStart[] = "http://www."; and then use sizeof(httpWWWStart)-1,
or use NS_NAMED_LITERAL_STRING and then get the length of that. That will
almost certainly end up
messier, though, so its probably not worht it.

In any case, add a comment reminding people to update the two numbers if they
change the match condition.

>Index: nsGlobalHistory.h
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/components/history/src/nsGlobalHistory.h,v
>retrieving revision 1.33
>diff -u -r1.33 nsGlobalHistory.h
>--- nsGlobalHistory.h	23 Mar 2002 21:23:48 -0000	1.33
>+++ nsGlobalHistory.h	12 Apr 2002 12:27:14 -0000
>@@ -215,7 +215,9 @@
>   PRBool AutoCompleteCompare(nsAString& aHistoryURL, 
>                              const nsAString& aUserURL,
>                              AutocompleteExclude* aExclude);
>-
>+  static int PR_CALLBACK 
>+  AutoCompleteSortComparison(const void *v1, const void *v2, void *unused);
>+  

Doesn't this have to be:

PR_STATIC_CALLBACK(int)
AutoCompleteSortComparison(const void *v1, const void *v2, void *unused);

- I think there is some platform which cares which order the PR_CALLBACK vs the
static goes

    
    

    
  


  
Attaching a new patch which addresses the 3 issues bbaetz@student.usyd.edu.au
raised in his review.

        Attachment #78885 -
        Attachment is obsolete: true

    
    

    
  
The returns can be simplified:

+    return (item1count < item2count) ? 1 : -1;
+    return o2 > o1 ? -1 : 1;

should be:

+    return item2count - item1count;
+    return o1 - o2;

This sort of subtraction is common in sort comparison functions.

    
    

    
  


  
Attaching a new patch which addresses suggestions made by Chris about
simplifying the comparisons.

        Attachment #79137 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 79240 [details] [diff] [review]
Aucomplete hybrid sort - visit count, etc




> int PR_CALLBACK 
>-AutoCompleteSortComparison(const void *v1, const void *v2, void *unused) 
>+nsGlobalHistory::AutoCompleteSortComparison(const void *v1, const void *v2,
>+                                            void *closure) 

What worries me most about this is the amount of work that's done with each
comparison.

anyway, here are some thoughts:
>-  nsAutoString s1;
>+  // get URLs
>+  nsAutoString s1, s2;

"s1"? "s2"? some better names here. short obscure variables aren't buying us
anything :)
>+
>+  // Favour websites and webpaths more than webpages by boosting 
>+  // their visit count.  This assumes that URLs have been normalized, 
>+  // appending a trailing '/'.
>+  PRBool ts1 = PR_FALSE, ts2 = PR_FALSE;

again "ts1"? What is that?

>+  if (!s1.IsEmpty())
>+  {
>+    ts1 = s1.Last() == PRUnichar('/');

Can you be explicity with order of operations here? i.e. use paretheses? 
make it obvious to the reader what you're intending here

>+    if (ts1)
>+      item1count += 5;

What's "5"? If this is a magic value, at least make the 5 a #define, and 
give the #define a good name. if we're trying to give it a higher priority,
adding seems wrong. 
We should be multiplying (I suggest *2 or some other obvious multiple of 2)
Adding 5 to a site that's been visited once increases its visit count
by 500%, whereas adding 5 to a site that's visited 200 times increases its
visit count by 2.5%!

>+  {
>+    // Favour websites and webpaths more than webpages
>+    if (ts1 && !ts2) return -1;     // s1 is a website/path, s2 isn't
>+    if (!ts1 && ts2) return  1;     // s1 isn't a website/path, s2 is
>+
>+    // two websites/paths - ignore http://www. and http:// prefixes 
>+    // for comparison purposes this logic must match with 
>+    // nsGlobalHistory::nsGlobalHistory()
>+    NS_NAMED_LITERAL_STRING(hwStr, "http://www.");
>+    NS_NAMED_LITERAL_STRING(hStr, "http://");
>+    NS_NAMED_LITERAL_STRING(hswStr, "https://www.");
>+    NS_NAMED_LITERAL_STRING(hsStr, "https://");
>+    NS_NAMED_LITERAL_STRING(ffStr, "ftp://ftp.");
>+    NS_NAMED_LITERAL_STRING(fStr, "ftp://");

This is all fine and dandy, but I'm wondering if there's a way to avoid
creating all these objects on every comparison.
Maybe we can make a closure object which contains both the nsGlobalHistory
pointer, and a pointer to all these objects.

In fact, I'm thinking that array (not a nsVoidArray, just a
nsDependentString&[] or whatever)
because then you could turn this into a loop:

>+
>+    // find a starting position in the string, just past any of the 
>+    // above prefixes.  Only check for the prefix once, in the far 
>+    // left of the string - it is assumed there is no whitespace.
>+    PRInt32 o1 = 0, o2 = 0;
>+    if      (s1.Find(hwStr, 0, 1) == 0) o1 = hwStr.Length();
>+    else if (s1.Find(hStr,  0, 1) == 0) o1 = hStr.Length();
>+    else if (s1.Find(hswStr,0, 1) == 0) o1 = hswStr.Length();
>+    else if (s1.Find(hsStr, 0, 1) == 0) o1 = hsStr.Length();
>+    else if (s1.Find(ffStr, 0, 1) == 0) o1 = ffStr.Length();
>+    else if (s1.Find(fStr,  0, 1) == 0) o1 = fStr.Length();
>+
>+    if      (s2.Find(hwStr, 0, 1) == 0) o2 = hwStr.Length();
>+    else if (s2.Find(hStr,  0, 1) == 0) o2 = hStr.Length();
>+    else if (s2.Find(hswStr,0, 1) == 0) o2 = hswStr.Length();
>+    else if (s2.Find(hsStr, 0, 1) == 0) o2 = hsStr.Length();
>+    else if (s2.Find(ffStr, 0, 1) == 0) o2 = ffStr.Length();
>+    else if (s2.Find(fStr,  0, 1) == 0) o2 = fStr.Length();

which would cut down on code size.

I don't know if you can do this, but maybe something like
struct autoCompleteSortClosure {
  nsGlobalHistory* history;
  size_t prefixCount;
  nsDependentString& [] prefixes;
};

then I think maybe you can declare:
autoCompleteSortClosure closure = { 
  this, 
  6, 
  { NS_LITERAL_STRING("http://www."), ...}};

(I might be wrong about being able to delcare this, but give it a whirl)

Other than that, nice use of literal strings and substrings! :)

        Attachment #79240 -
        Flags: needs-work+

    
    

    
  


  
Thanks for the review Alec!  Here is a new patch which addresses the coding
issues you raised.  Also, here are some replies to your specific concerns:

1. Performance: I've tested the patch with a 300Mhz machine and I don't notice
any problems.	I haven't done any profiling, but I assume that just as much or
more time is spent generating the list of autocomplete canditates from the
history to start with.	 Our autocomplete ordering will probably save the user
time anyway in net terms (vs the current strcmp() ordering).

2. Use of addition (instead of multiplication) to boost the visit counts of
non-page urls: I've added some documentation to the patch about the reasons for
this - it is intentional.   Basically, for urls with large visit counts it is
assumed that for all urls (whether web pages, sites or paths) the likelyhood of
them being visited again is proportional to their visit count and so they can
be sorted in roughly visit count order. For urls with small visit counts it is
assumed that web sites & paths are more likely to be visited again than web
pages and so their visit counts are boosted by a greater percentage.  More
details are listed in the inline comments in the code.

        Attachment #79240 -
        Attachment is obsolete: true

    
    

    
  
ok overall this looks good. The one issue I still have left (sorry, I just
noticed this) is the use of Find() - really, we only care if the string STARTS
with the string in question. on false matches, it will iterate through the
string every time.

(i.e. looking for "ftp://" in "http://foo.bar" will result in string comparisons
with "http:/", "ttp://", "tp://f", and so forth.


 You should do something like

PRUint32 prefixLen = prefix.Length();
if (url.Length() >= prefixLen && 
    Substring(url, prefixLen) == prefix) {
 ...
}


    
    

    
  
I may be wrong but I thought that using a value of 1 for the last parameter of
Find() specified that only the very front of the string should be searched for a
match (ie. 1 comparison iteration).   The inline documentation for this
parameter says "tells us how many iterations to make starting at the given offset".

    
    

    
  


  
Attaching a new patch.	The only change is some more inline documentation I've
added regarding the last issue Alec raised, and a suggestion Chris raised to
link back to the bug # for anyone interested in knowing about the original
design and reasoning behind the sort implementation.  Hopefully this patch is
now ready for primetime.

        Attachment #79443 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 79606 [details] [diff] [review]
Aucomplete hybrid sort - visit count, etc

sr=alecf

I'd say this is trunk-worthy now. I forsee needing to tweak it in the future,
as it gets more exposure.

I don't think we should try for the branch - it works well enough and I'd
really rather keep the risk to the trunk.

        Attachment #79606 -
        Flags: superreview+

    
    

    
  
Now we have a sr=alecf, we are waiting for someone to provide a r=.   Blaker, 
hewitt, anyone - can you help us out here?

    
    

    
  
Comment on attachment 79606 [details] [diff] [review]
Aucomplete hybrid sort - visit count, etc

r=blake

        Attachment #79606 -
        Flags: review+

    
    

    
  
This has been checked into the trunk (for Mozilla 1.1).  Unless 
drivers@mozilla.org have a change of heart, it won't be checked into Mozilla 
1.0.   Regardless, give the trunk builds a tryout and send me any comments you 
have.  Thank-you to everyone who helped out with this bug - 
cbsears_sf@yahoo.com, alecf@netscape.com & blaker@netscape.com.

    
    

    
  
Resolving...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
  
Blocks: 140404

    
    

    
  
I noticed this feature works with ftp, http, https prefixes. What about the
file:// prefix?

    
    

    
  
Gavin

I assume you are using a nightly.  People will be getting some experience
with the new sort.

> I noticed this feature works with ftp, http, https prefixes.
> What about the file:// prefix?

You are correct.

The nsGlobalHistory::nsGlobalHistory() constructor has a list of prefixes.
It predated the sort fix.  I don't know if this was a policy decision
or an oversight.
Chris

    
    

    
  
*** Bug 146607 has been marked as a duplicate of this bug. ***

    
    

    
  
I'm proud to annouce the public release of version 1.0 of the Autocomplete Manager, which fixes this bug by means of an extension! The extension provides advanced features for the address Autocomplete framework in Firefox. Features include:
- matching against page titles
- matching against bookmark addresses and bookmark names
- matching any part of the domain name
- various sorting criteria for suggested entries, including alphabetical, most-frequently-visited and most-recently-visited
- resorting the suggestion list on the fly according to different criteria
- showing/hiding page titles and visit counts
- setting the number of visible entries on the popup
- define the truncation for long addresses
- numerous fixes for Autocomplete-related bugs

The extension can also function as a rudimentary History Manager. More details, as well as the installation package, are available at http://www.cs.ucla.edu/~nikitas/acmanager

Please let me know of any suggestions/bugs.

Thank you!

    
    

    
  
I'm afraid your extension is severely broken.  For instance, I was unable to go to any URL which I have not visited before.  Still, I'm glad you're working on the problem.

Since this bug is resolved, the discussion should probably go elsewhere.

    
    

    
  
I believe the problem is specific to your configuration. It has been working fine for me and some beta testers. Let's take this offline. Can you please send me your browser version, operating system, and a brief description of the problems you are seeing?

Thank you!

nikitas
Product: Core → SeaMonkey

    
    

    
  
'm running iThemes Security Version 4.2.2 and WordPress 3.9.1 with nginx.

I noticed some issues with scripts loading on edit pages in the WP admin. It seems that some of the security features I've enabled through the plugin are incompatible with something on the edit page. The only thing out of the ordinary is Yoat SEO's metabox.
http://mobihot.in
The following was returning a 403 when editing a post

    
    

    
  
Comment on attachment 79606 [details] [diff] [review]
Aucomplete hybrid sort - visit count, etc

Review of attachment 79606 [details] [diff] [review]:
-----------------------------------------------------------------

Co to znaczy ni wie nikt ale cos oznacza http://radioreddit.com http://xxxx-video.com <a href="http://x-vidos.com">xvidos</a>

    
    

    
  
(In reply to lukasz77w from comment #101)
> Comment on attachment 79606 [details] [diff] [review]
> Aucomplete hybrid sort - visit count, etc
> 
> Review of attachment 79606 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Co to znaczy ni wie nikt ale cos oznacza http://radioreddit.com
> http://xxxx-video.com <a href="http://x-vidos.com">xvidos</a>

no i oczywiscie http://xx-videos.com
http://xx-nx.com

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: