Closed Bug 128341 Opened 23 years ago Closed 15 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: 23 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: 23 years ago → 23 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: 23 years ago → 20 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: 20 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.