You know how it saves (or will eventually save) the last 15 url's you have manually typed into the url box? How about a feature that makes it so that it will not save ones that do not work for one reason or another. (ie they return 404 error's , server does not exist error's , access denied etc.) . Having 'bad' url's in the combo box is esentually a waste of space and does not do anyone any good. If someone needs to fill the box with useless stuff to eliminate url's they don't want seen then they should remove them via the delete button under prefrences of by manually editing the prefs50.js file. Another possible feature may be to have it so that it will not save url's from a specific domain into the box. If your at a site you dont want others to have access to then you could add it to a list of "don't ask dont tell" url's that would not go into the url combo box even if they are valid. This would be meant to be used as a privacy feature, but could be abused by 'kids' going to sites that they shoulden't go to and dont wana get caught so that would be a concern.

Hmmmm, I like these ideas ...

Move to M20.

Upating QA contact.

spam, changing selected qa contact on selected bugs from paulmac@netscape.com to claudius@netscape.com

Move to "Future" milestone.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

-> urlbar history

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

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

I disagree with this proposal. If I want to correct the misspelled URL later, I have to retype all of it. Example: URLs that redirect to a 404 page, if mistyped. There are a lot of other cases, whwere the proposed behahvious is unwanted. The urlbar history should work just like any other history of a textfield - keep the history of *text* I typed, not the history of URLs I visited using the urlbar. I suggest WONTFIX.

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

-should be split into a new bug- if we allowed for styled menus then pages that failed to load could be red italic, and pages that were redirected could be green underline. reminder: ie allows you to delete entries by selecting them (arrows/mouse) and pressing the delete key. -

> reminder: ie allows you to delete entries by selecting them (arrows/mouse) and > pressing the delete key. Cool. File a bug?

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

people have been bitching about this problem for months/years (note the 4-digit bug #) I am NOT marking this WONTFIX.

You can bet that people will be bitching, if you fix this. At least I will. At least give me the option to keep the current behaviour.

I'm quaking in my boots.

since the type in history is just that - type in history I think it should stay that way. If you wanna go making it smart about url loading then it'll just look like a poor implementation of loaded url history and we'll see many more bugs and requests. I think a good sol'n is to leave it alone and implement the ability to delete from this menu for those people who feel oppressed by the presence of non working urls and such.

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

The problem is, the purpose of the history is to keep track of web pages, not your mistakes or whatever text you've chosen to put there. Given this purpose, it makes sense to streamline the system (see other bugs on ignoring http:// and trailing "/"'s). The fact is, with autocomplete, if I screw up once in typing an url, it comes back to haunt me every single time I want to go there again. Type in www.mozillazine.com instead of www.mozillazine.org just once, and from then on the first, incorrect entry pops up first and I get very annoyed.

> The problem is, the purpose of the history is to keep track of web pages, not > your mistakes or whatever text you've chosen to put there This is where we disagree: We do have a "history" of visited webpages, but *this* (urlbar) isn't it. *This* is the history of the urlbar *textfield* and shows what I types intp that textfield, not what the browser made out of it. Again: It is not uncommon that I mistype the URL and the braindead server *redirects* me to a 404 page. With your proposal, the 404 page would end up in the urlbar history, but not what I typed. -> I have to reenter the full URL again. Repeat x times until success. Other example: I type www.sun.com and I get <http://www.sun.com/javasomething/somescript.jsp?visitor-id=465678578345685768&session-id=cgfjrt7kzst6u47k47ik468k768r768i578o568ko579ol5789o89zu9h978nh9u>. What would you like to store in the urlbar history? (I'm sure, I could come up with several other case, given enough time.) How do you want to solve these problems?

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

Okay. The way I see it there are two good sol'ns and these might appease both sides. 1) The URL bar keeps the history of everything, *but* all invalids should be marked and flushed after a Session( or a timeout ). That would allow for the invalids to go away while also keeping the incorrect URLs around a little while so people don't have to retype to whole URL. 2) In the History or "Smart Browsing", an option to ignore Autocomplete of invalid URLs is allowed. Also an option could be given to supply a timeout, at which time invalids are flushed. In any case, this would mean that URLs need to be marked as valid or invalid and then dealt with by that marker. Also by supplying the option, the behavior is left up to the user. By default this behavior should be set to allow the invalid to be added, but be flushed at the end of a session( or a 5 minute timeout ). That's my $.02

Brain Sea, nice suggestions. 1) That would be an acceptable compromise for me, if required. 2) Assuming "autocomplete" = the completion inline in the textfield. It is fine with me to remove invalid URLs from autocomplete, or even to remove autocomplete altogether. There's a bug about each of both options, the former being closed as DUP of this one.

I believe the way autocomplete is implemented now is the way you're describing. I'm not suggesting we change how autocomplete operates - just the "completeness" of the list it searches through to autocomplete. I'm not sure exactly how much code has to change for this to work. I haven't looked at the Mozilla source in about a year, and I hope lots has changed since them :-)

Sounds good to me. Invalid urls could have a grey, red, or italics font to distinguish them. I don't think the gods would be too happy with a pref for the timeout; explaining it would take a lot. Maybe they should just be cleared at the end of a session.

Some kind of pref is needed to tell if the user wants those URL even cleared out. The timeout pref would only be a convience of the few who might want it. People are just going to have to try and explain to the gods why this new preference is needed, and also why this new pref won't hinder anything, but only help. To hardcode in a timeout would be a bad thing for the "future", IMO.

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

reassign url bar bugs to new owner..

Joe was dying to have these bugs. Who am I to say no?

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

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

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

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

11 dups and counting, what's happened to the mostfreq keyword? Regarding the "I might have misstyped the url and want to correct it later" argument. I would guess that if you end up on a page with an error you will correct it immediatly, which will make the right url end up in the list.

> I would guess that if you end up on a page with an error you will > correct it immediatly, which will make the right url end up in the list. As I said, what happens if the braindead freespace providers *redirect* me to a 404 URL? Try for example <http://www.fortunecitx.co.uk/abce/>, then correct to <http://www.fortunecitx.co.uk/abcd/>. For first URL redirects you to <http://www.fortunecity.co.uk/error/error404.html>.

eh, s/citx/city/, of course. mostfreq is gone in favor of a certain query page.

bug 126320 seems to be related...

One thing that I haven't seen mentioned here is -- what if you type a URL into the box and the name doesn't resolve? I have several entries in my URL bar where I have transposed the "r" and "g" in .org, and the g sorts first, so whenever I type in, for example, "http://www.slashdot.o" the urlbar pops up "http://www.slashdot.ogr". It seems like this might be easier to check for than a 404 error, and one of the more obvious reasons why you wouldn't want a particular URL in the history.

What IE seems to do is IMHO very nice. It adds urls to the location-dropdown when a page is successfully loaded. This also avoids getting double urls for exampel when typing "www.mozilla.org/projects/xslt". In moz that currently results in two links being added; "www.mozilla.org/projects/xslt" and "www.mozilla.org/projects/xslt/", which is a bit annoying at times

Bug 66049 (about incorrect URLs in *autocomplete*, not the dropdown) has been marked a dup of this one for technical reasons, while I think these bugs are really very different. What about this: The autocomplete does not only save the URLs, but also information about e.g. the HTTP status code recieved and the time it was added / last tried. That way, the code could distinguish 404, forwards (the mentioned xslt -> xslt/) and "good" urls during when it tries to *use* the data (not store it). For example, autocomplete could skip all 404s, but use forwards (because the forwarded url might be easier to remember and thus the one typed by the user, compare the many go.to/site urls). The dropdown could show all URLs, but mark 404s with a different icon and maybe not show them at all 2 days after they have been last tried (2 days to give the user a chance to retry servers which are down, websites that are temporarily broken etc.).

Refining my suggestion a bit more, esp. the usage of "autocomplete": > The autocomplete does not only save the URLs... I really meant the urlbar widget here. > For example, autocomplete could skip all 404s, but use forwards [...] > The dropdown could show all URLs, Actually, we have 3 cases to differentiate: 1. the completion *within* the textfield (that's what meant with "autocomplete" above) 2. the alternative suggestions shown in the dropdown while you type 3. the dropdown that appears when you click the right down arrow without touching the keyboard (that's what I meant with "dropdown" above) I think the options in case 2 should be the same as in option 3 (not 1). That way, you can still reach URLs (even 404s) that are already thrown out of the list of only 15 or so URLs that case 3 shows, without annoying users who just want to have "www.slash" completed despite a previous typo like "www.slashdot.ogr".

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

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

I propose that we just add a way for users to delete items from the URL bar. For example when i start type 'www.mozilla.o', and it auto completes to 'www.mozilla.ogr', I can right-click on the item, and select 'delete' to delete this from the url bar history. So in the future, it will no longer suggest 'www.mozilla.ogr' again. This will put the burden on the user to delete invalid urls if they desire to. As oppose to Mozilla trying to guess what the user wants.

I agree that that might be a nice thing to support in *addition* to this. IMHO we should not try to hide "sucky" UI by saying it's the responsibility of the user.

What Charles suggests is a good solution for occasional typos and dead urls. I've even wished I could do that a couple times. However, as many times as I type "rog" instead of "org," the time I would spend deleting incorrect URLs from the url bar history would be better spent skipping over those urls with the tab key.

I absolutely can't stand the history keeping track of invalid URLs. What's worse, it doesn't seem to remember valid URLs! For example, I type in a page for the weather: www.nws.noaa.gov/er/okx Mozilla 1.1b never seens to remember this URL. I once mistyped www.nws.bnl.gov/er/okx (which is an outdated url) and Mozilla remembers this, even though it's never been valid. URL bar history never remembers the valid one. Reading through the threads about people wanting it to stay a history of what was typed versus valid sites typed, well, I'm sympathetic towards not keeping bad URLs. To be the behavior is awful. If nothing else, make the behavior a preference. I'm also open to being able to edit this. And why not have a hard-coded preferred list that's never deleted (based on Favorites/Bookmarks?)

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

how about upping the Severity, this bug is very annoying, not to mention old.

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

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

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

This issue was first filed in Nov 1999, and it is now Oct 2003, and it still has not been resolved. Not to mention 20 duplicates, one of them being my own. Looking at the preferences in Mozilla 1.5rc2 I see there is a section 'Navigator -> Smart Browsing' and in that section an 'autocomplete' option. Opening the 'advanced' view I see a bunch of options, but nothing related to this bug. Could we not add the option that people have been screaming about and listing it as an option in this window? Maybe something like: - Match only web sites that have been found - Match only web pages that have been found The second option would be a dependent on the first. At least by adding by adding this feature and listing it in the indicated options, it should make most people happy. Now the only question is do we activate by default? Given the general the general concensus, I would say yes and allow the power users to turn this off.

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

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

(In reply to comment #54) > This issue was first filed in Nov 1999, and it is now Oct 2003, and it still > has not been resolved. ... > > ... option in this window? Maybe something like: > > - Match only web sites that have been found > - Match only web pages that have been found > Just to clarify what you mean: if I type go to "foobar.com/somepage", the match only web sites would show "foobar.com" while the match only web pages would include "foobar.com/somepage"? I think that's vague wording. I had to think about it just to ask for clarification. Better option wording: - Exclude invalid web page addressess - Match only domain names (not pages within a site) One doesn't have to depend on another. BTW, I would also add an option (not quite related to this bug): - Exclude addresses for submitted forms > At least by adding by adding this feature and listing it in the indicated > options, it should make most people happy. > > Now the only question is do we activate by default? Given the general > the general concensus, I would say yes and allow the power users to > turn this off. I agree.

Opened bug 244535 on the about:about page having the same filling-up-with-typos-and-guesses problem, which obscures the real about: options.

A simple algorithm to apply here would be: - if this is the first time a URL has been seen (i.e. URL is not already in the drop-down URL list), and an object is not returned (either because the URL is 404 or DNS does not resolve) do not add URL to list. - if the URL is already in the list, or was entered from the list, and an object is not returned, do nothing. Do mpt remove previously valid URLs from the list. This simple first-entry check prevents typo'd URLs from being added to the list, while retaining all URLs that pass this first sanity check without deleting them later should they be unreachable. It should prevent a lot of typo'd noise from entering the list.

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

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

I agree with this comment. I think the Severity and Priority of this bug needs to be escalated. It has been neglected for too long. It is a most annoying bug. Let's make it right for the majority of the users out there and do it in a timely manner. (In reply to comment #48) > I absolutely can't stand the history keeping track of invalid URLs. What's > worse, it doesn't seem to remember valid URLs! > > For example, I type in a page for the weather: www.nws.noaa.gov/er/okx > > Mozilla 1.1b never seens to remember this URL. I once mistyped > www.nws.bnl.gov/er/okx (which is an outdated url) and Mozilla remembers this, > even though it's never been valid. URL bar history never remembers the valid one. > > Reading through the threads about people wanting it to stay a history of what > was typed versus valid sites typed, well, I'm sympathetic towards not keeping > bad URLs. To be the behavior is awful. > > If nothing else, make the behavior a preference. > > I'm also open to being able to edit this. And why not have a hard-coded > preferred list that's never deleted (based on Favorites/Bookmarks?)

Describing a very easy way to fix this behaviour, a year after I first described it. nothing has happened in the interim. A simple algorithm to apply here would be: - if this is the first time a URL has been seen (i.e. URL is not already in the drop-down URL list), and an object is not returned (either because the URL is 404 or DNS does not resolve) simply do not add URL to list. - if the URL is already in the list, or was entered from the list, and an object is not returned, do nothing. Do not remove previously valid URLs from the list. This simple first-entry check prevents typo'd URLs from being added to the list, while retaining all URLs that pass this first sanity check without deleting them later should they be unreachable. It should prevent a lot of typo'd noise from entering the list.

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

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

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

==> me

This fixes it and actually avoids purging redirected URLs (so BenB should be happy :)). I thought it would be sufficient to only try to purge if userTypedValue wasn't null but userTypedValue was null in a few cases where I typed the URL (userTypedValue gets mucked with all over the place).

Comment on attachment 204513 [details] [diff] [review] try to purge invalid typed URLs from history I just reviewed this patch for bug 317819 ;-)

Comment on attachment 204552 [details] [diff] [review] how 'bout this one >+ // URI made it into global hostory because it was typed Where does this happen?

as far as I can tell, they go through addToUrlbarHistory http://lxr.mozilla.org/seamonkey/search?string=addtourlbarhistory checking the userTypedValue is important because the actual URI might have a prepended www.

looks good, but I'll test it first

Comment on attachment 204552 [details] [diff] [review] how 'bout this one <sigh> This patch actually fixes bug 66049. I think this bug is (mostly) unfixable. I could have it go through the strings in the dropdown history and see if any of them match the URI or userTypedUrl, but in most cases, it won't.

Comment on attachment 204552 [details] [diff] [review] how 'bout this one >+ if (typedUrl) >+ uri = gURIFixup.createFixupURI(typedUrl, 0); That needs to follow a if (!gURIFixup) gURIFixup = Components.classes["@mozilla.org/docshell/urifixup;1"] .getService(nsIURIFixup);

Comment on attachment 204552 [details] [diff] [review] how 'bout this one >+ // URI made it into global hostory because it was typed but failed >+ // to load, so now remove it so it doesn't clutter autocomplete. >+ if (!Components.isSuccessCode(aStatus)) { Make this comment a little clearer, and fix the spelling mistake. How about "URI made it into the global history, but because it failed to load, remove it so it doesn't clutter autocomplete." Otherwise it looks good. r=db48x

(In reply to comment #70) > Created an attachment (id=204552) [edit] > how 'bout this one > I tried the patch but the problem seems to remain, partly. If I write www.mozilla.ogr in the location bar it will still try to autocomplete it when I enter www.mozilla until I restart firefox. Wouldn't it be better if the invalid URL's isn't saved at all?

Simon: this patch is only to SeaMonkey. Firefox would need another patch, although it could probably be very similar.

Location Bar really shouldn't be a core component, but I digress. Given that this is a seamonkey-only bug, someone who cares about this issue should file a new Firefox bug and nominate that.

(In reply to comment #79) > Given that this is a seamonkey-only bug, someone who cares about this issue > should file a new Firefox bug and nominate that. Bug 322511 filed

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

Comment on attachment 204552 [details] [diff] [review] how 'bout this one This patch appears to be for bug 66049, and you haven't answered comment #71 correctly anyway.

This problem still affects Firefox 2.0. To fix it: if a new not-seen-before url doesn't resolve to or return anything, don't add it to the list of known urls. I'm not asking you to remove a url from the list when it goes 404, since that might be temporary, or when a site is down, again temporary. I'm not asking you to edit the list in any way. Purging the list is not desirable for a number of reasons; you might purge something that's wanted. I'm asking you to be more selective about what you let on the list in the first place. If it doesn't return anything, don't let it on the list. Raise the barrier to entry. I can't believe that this simple behaviour change is still unfixed after seven years. I'm staring years of typing errors in the face, so autocomplete selection is pretty useless for me.

You can delete entries from the autocomplete list by highlighting and doing a "shift-del" on the bad entry. Doing that cleanup will allow you to start using autocomplete again. Of course it would still be better to not add it in the first place, hence this bug report.

I am not doing shift-del on thousands of invalid entries. As I said before: *** This problem still affects Firefox 2.0. To fix it: if a new not-seen-before url doesn't resolve to or return anything, don't add it to the list of known urls. I'm not asking you to remove a url from the list when it goes 404, since that might be temporary, or when a site is down, again temporary. I'm not asking you to edit the list in any way. Purging the list is not desirable for a number of reasons; you might purge something that's wanted. I'm asking you to be more selective about what you let on the list in the first place. If it doesn't return anything, don't let it on the list. Raise the barrier to entry. I can't believe that this simple behaviour change is still unfixed after seven years. I'm staring years of typing errors in the face, so autocomplete selection is pretty useless for me. *** So, create a list of newly-seen urls, and only move a url that was entered from that table to the list of urls for the drop-down list once it has been shown to resolve to something. (What the urls resolve to might change over time, but that doesn't matter, and each url shouldn't be updated depending on a 301/302 redirect - this is about matching whatever shortcut the user types.) Hmmpph, programmers with no UI experience.

I think you are confusing things when you talk about "thousands of invalid entries". The bug is about the location *dropdown* which lists the last 20 or so *manually* entered URLs, not the *autocomplete* which appears when you start typing.

Lucky I entered the comments twice to learn this. Both the autocomplete and the location dropdown appear in exactly the same place and look identical, so it's reasonable for users to conflate the two - helped by the bugzilla category "Location bar and dropdown". And I'm complaining about all the *manually* entered but *mistyped* urls going nowhere that fill up the automcomplete list. Poor choice of terminology and UI design IMO. If you want them to be perceived as different, why make them look the same? Since autocomplete is claimed to be a separate issue (despite it being same dropdown on screen listing manually mistyped urls) I've opened bug 366641 on this. Also, I see the history sidebar (when it's working...) also records and shows mistyped urls - see comments to bug 366642.

> Location Bar really shouldn't be a core component, but I digress. > > Given that this is a seamonkey-only bug, someone who cares about this issue > should file a new Firefox bug and nominate that. Shouldn't the Product be changed to Mozilla Application Suite if this is SeaMonkey-only? It seems a bit confusing to me to list it under Core, which implies that this still affects Firefox, when it does not.

I have justed with Firefox 2.0.0.7 and it appears to be an issue there. I haven't yet tested with the latest 3.x builds though.

Yes it is still an issue in Firefox 2.x; it has been fixed on the trunk and it will be fixed in Firefox 3 with the move to SQLite and Places.

Bug 322511 is the Firefox version of this bug.(In reply to comment #89) > I have justed with Firefox 2.0.0.7 and it appears to be an issue there. I > haven't yet tested with the latest 3.x builds though. > See comment 80

This would appear to be fixed in recent builds, can this 13 year old issue be closed or not? :)

Yes, I tried in version 2.14 and it seems to be fixed when running proxy-less. (The embedded rounded-corners error pages are stored in history but do not show up in location bar.) My squid proxy returns 503 Service Unavailable for these bad URLs which /do/ get stored into the location bar. Does the scope of this bug cover that?

This bug blocks bug 66049, which is dupe of bug 126320, which applied to SeaMonkey and Firefox before Places, and is now fixed. Places were supposed to fix it for Firefox. Duplicates of this bug have not been changed after 2008 (when Firefox 3.0 with Places was released). So it does not apply to Firefox. Due to bug 126320 comment 8, I am not sure it is exactly a duplicate, so I will only change the Blocks field.