Closed Bug 128341 Opened 19 years ago Closed 12 years ago

Autocomplete suggestions favor specific urls over top-level page

Categories

(SeaMonkey :: Autocomplete, defect)

Product:
SeaMonkey
Component:
Autocomplete
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mikepinkerton, Unassigned)

Details

(Keywords: regression) 

autocomplete used to work fine for me, but after a pull from 2/28, it only
suggests long, specific urls rather than the top of a site.

for instance, before i'd type in "www.washi" and "www.washingtonpost.com" would
be the first suggestion. now i can't even see that suggested, and lots of
internal pages are at the top of the list.

autocomplete is now totally useless.
autocomplete is now totally useless in 099. we have to fix before we branch.
Keywords: mozilla0.9.9, regression
Blocks: 122050
Keywords: nsbeta1
OS: MacOS X → All
Hardware: Macintosh → All
I was seeng the same thing, but for 'www.ny...' and not getting
'http://www.nytimes.com/' offered. It only showed detailed URLs.

At blake's suggestion, I then typed just 'nyt..' and was then offered
'http://www.nytimes.com/'. After that, it seemed to have fixed itself.
To my mind, the way autocompletion currently works in Mozilla is not very
useful. It was much better in Netscape 4. The following example illustrates this:

I've browsed several directories on a website:

www.website.com/aardvark
www.website.com/giraffe
www.website.com/zebra

But I've not browsed the root dir.

Now, say I want to go to page in zebra. I start by typing 'webs' and I get
autocomplete for the first website.com/aardvark entry, by alphabet, and NOT the
first unique peice of the URL that matches as Netscape 4 did - Netscape 4 would
give me 'website.com/' as the first autocomplete offering which then allowed to
type 'z' and get to where I wanted to go. This means in Mozilla I either accept
the autocomplete and delete the part I don't want (shift-left arrow doesn't work
as expected either) or I use page down to go through everything until I get to
zebra.
Here is a start and the checkins to Bonsai between 02/27/2002 08:00 and
02/28/2002 12:00 :

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=02%2F27%2F02+08%3A00&maxdate=02%2F28%2F02+12%3A00&cvsroot=%2Fcvsroot

WebBrowserpersist was in there bug 125070, and backed out yesterday or the day
before.. 

nsGlobalHistory for typing in URL's was fixed, but may have caused this: bug
127506.  

nsLocalFile changes, and bug 127189 for autocomplete.xul.

this bug is about how the behavior _regressed_, not for general commentary on
how one would like it to work.
I've heard it suggested that this was just a case of a few days of history
getting corrupted and that clearing history fixes it. Can anyone confirm?
if that's the case, then everybody's history got corrupted, and we have some
serious data corruption bugs on our hands. either way, it's a big deal.
It would be everyone who used a nightly within about a week's time. I don't see
what we would do about that.
clearing both global history and location bar does seem to have solved the
problem here.
why doesn't anyone seem interested in finding out what happened? i doubt the
problem has gone away, just the people who first saw it have revisited the sites
and don't see it (as much) anymore. i don't think we had corruption for a week
and then it vanished.
Nav triage team needs info: can anyone reproduce this in a current build, with a
new profile?
Whiteboard: [need info]
Why do you assume I know what happened? I have a theory as to the problem,
that's why I asked that people test it. And testing seems to confirm it.  I
don't doubt the problem has gone away. As I said, I checked in something not
quite right and then fixed it about a week later.

Basically, the problem is that I had been setting the value for a row in your
history database to 0. instead of removing the row altogether.  If I'm right.
If I understand this then there were a few days where if you used the nightly
builds you may have corrupted your history and if you didn't use those nightly
builds then you're not affected. If this is the case then it is limited to
developers and other nightly build testers and not critical to 0.9.9.
No longer blocks: 122050
Er, "Why do you assume I know what happened" is supposed to read "Why do you
assume I don't know what happened". It rather changes the meaning of my comment.
Ok, now you all got me confused.  Is the specific 'corruption' that:

* http://www.google.co.nz will be favored over
* http://www.google.com due to the '.' being sorted before the 'm'?  i.e.,
autocomplete is *sorting* entries, rather than showing the most appropriate
(which would be google.com - since I visit it many times every day, so the
history should have quite a few entries of it already.)

That's the problem that people pointed me to this bug for. Sorry if I'm in the
wrong bug.
Håkan: It sounds like you're talking about bug 78270 ("Order autocomplete
completion candidates by time or frequency"). And, if you're wondering why that
bug has been Futured, then that makes two of us ;).
hwaara: that's not the bug that i filed here. this bug favors
www.foo.com/bar/baz/mango/crazy.html over www.foo.com.
nsbeta1- per Nav triage team, since it appears likely to be an intermittent
problem in Feb. 27/28 nightlies.  ->1.2.  Please renominate as new data warrants.

BTW, why is this marked critical severity?
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
this continues to happen for me with a build from 3/13. autocomplete works fine
for a few days and then blam, it won't show me any top-level urls.

this is critical because it makes autocomplete totally useless, and makes it
pretty darn hard to use the browser.

requesting re-triage. this isn't isolated to a couple of builds, it's ongoing
data corruption (yes, my past browsing history is critical data to me).
Keywords: nsbeta1- → nsbeta1
Are you saying the history data is lost?
If Asa's comment#13 is correct then this is not even a bug anymore and should be
closed, much less minused. It is not a valid test to continue to use a
previously corrupted history DB.
If this can't be reproduced in a current build with a recent profile (say post 3/6).

Mike are you saying this happened to you with a new build and old profile, after
you cleared your location bar history?
yes, claudius. that's what i'm saying.

I've seen this behaviour in a 0.9.9 build and a new profile. Typing 'google.com'
would autocomplete to 'google.com/search?mumblesomelongsearchstring'. Checking
the 'Match only website you've typed previously' checkbox fixed it. Shouldn't
this default to on?
I don't think we want that on. The fix should be to get it to work as it used 
to do. 
Claudius, did you check this on MacOS?  
I can't reproduce this on any OS in recent (3/22) builds. Then again, it's not
as if there are specific steps to trigger the condition. The problem described
in comment#3 is accurate, but I believe that to be a different issue.

Anecdotally, I can say I believe I've seen this on MacOSX but not reliably, and
not for some time now.
nsbeta1+ per Nav triage team, ->1.0, adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [need info] → [need info][adt3]
Target Milestone: mozilla1.2alpha → mozilla1.0
Whiteboard: [need info][adt3] → [adt3]
This problem seems to have been cleared up, marking as works for me. Reopen if
anyone is still seeing this with a post 3/15 build and history.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
still happens for me on a regular basis with new sites visited.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
with a trunk build from yesterday, i pitched my history and was able to
duplicate this in about a half an hour. i just registered for a new account at
blogspot.com and by the time i'd finished, www.blogspot.com was _nowhere to be
found_ on my autocomplete list. It was full of urls deep into the bowels of
blogspot.

This is a serious usability problem that cripples autocomplete.
Whiteboard: [adt3] → [adt2]
I am tempted to mark this invalid.  After playing with a number of url
combinations, this is what I have determined:

If you visit "blogspot.com", then "http://blogspot.com" will be added to your
history.  From then on, typing "www.blog" will NOT match on
"http://blogspot.com", because there is no "www" in this url.  Typing "blog"
will indeed match on this url.  I don't think we should just assume that all
urls that don't start with "www" will still work if we just tack it on there.  
as a matter of fact, I think I will
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
trust me, i'm not just omitting the www. prefix. autocomplete that will work at
one point will be pushed off the list 30 minutes later with other urls at that
same site.

why is this so difficult to comprehend? reopening.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I've also seen this now and then during the last month or two. I don't believe
it's any kind of user error. Suddenly google no longer autocompletes to anything
without a long search string and then after a while that url works again.
Irritating.
removing plus for re-triage, this sounds like high risk for uncertain benefit.
Keywords: nsbeta1+ → nsbeta1
nsbeta1- per Nav triage team
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1alpha
*sigh* i'm not asking for improvement, i'm asking to fix it back to the point of
before it was broken. The "uncertain benefit" of which you speak is just plain
working like it used to.

it's obvious nobody is ever going to give this bug the time of day. \/\/hatever.
Pink, are you still seeing this bug?  Does this bug actually cause Mozilla to
favor longer addresses, or does it just "forget to sort" by how many times you
visited each page?
yes, i still see this at times, and no, it's not forgetting to sort. the top of
the site isn't in the list at all.
nominating for buffy.
Keywords: nsbeta1- → nsbeta1
nsbeta1+/ADT3 per Nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2] → [adt3]
Nav triage team:  Behavior seems different now.  Has another checkin changed
this?  Can this be closed?
Keywords: nsbeta1+ → nsbeta1
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [adt3]
I'm not seeing any regression here... 0.9.7/8 seem to behave the same as 0.9.9
and 1.0.  all of them prefer some deeper-level URLs over some top-level URLs.

On the other hand, current trunk (20030103) seems to work ok.  With a different
profile, current trunk has the buggy behavior.

It is then tempting to blame this on corruption, but with the first profile I
mentioned, using old builds after using current trunk (which works fine)
restores the buggy behavior.  That is not consistent with corruption.
See bug 96700. This sounds like a duplicate. Related: bug 175725.
Product: Core → Mozilla Application Suite
Feel free to reopen if you disagree.

*** This bug has been marked as a duplicate of 96700 ***
Status: REOPENED → RESOLVED
Closed: 19 years ago → 17 years ago
Resolution: --- → DUPLICATE
This isn't a dup of bug 96700.  What this bug report describes is a bug, and if
the bug still exists, it would probably survive a fix for bug 96700.

I have not experienced this bug.  Has anyone experienced it lately, or should it
be marked as WFM?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
If I type "bug" in the URL, bugzilla.mozilla.org is the 12th autocomplete
suggestion, after saved queries, the query page, attatchment page, etc.
Andrew, what is the "visit count" in your global history for
bugzilla.mozilla.org and for the other URLs?  If you're using Seamonkey, I think
you can make a "visit count" column appear in the History window; if you're
using Firefox, you may have to install an extension (or use jwz's mork.pl) to
find out.
visit count for bugzilla.mozilla.org itself is 2.  There are 25 b.m.o URLs with
higher visit counts.  One saved query has a hit count of 480.

480, 216, 154, 111, 88, 67, 65, 54, 36, 34, 16, 2x6, 2x4, 10x3

the URLs are listed in visit count order in the dropdown except that the
toplevel URL is between 16 and the 6s
Assignee: hewitt → nobody
Status: REOPENED → NEW
QA Contact: claudius
Target Milestone: mozilla1.1alpha → ---
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Yes, it is there in SM 2.0b. For example I have visited http://www.google.at/ and http://www.google.at/search?hl=de&q=test&btnG=Google-Suche&meta=&aq=f&oq=. When I start typing www.google.a it will favor the longer over the shorter versions. This is annoying, since it is tricky to shorten the address without having it completed again.

pi
Status: UNCONFIRMED → NEW
The Smart Location bar will learn your preferences after a while, so this is either WFM or WONTFIX.
Status: NEW → RESOLVED
Closed: 17 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.