From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011126 BuildID: 2001112603 Can't find any dups of this... Reproducible: Always Steps to Reproduce: 1. Enable Location Bar Autocomplete 2. Visit http://mail.yahoo.se/ 3. Type mail.. in location bar. Actual Results: Autocomplete doesn't work Expected Results: The URL should be "autocompleted"

History->Global. The link you provided redirects to http://login.europe.yahoo.com/config/mail?.intl=se whirch is saved in location bar history, instead of mail.yahoo.se. Hense, only by typing "login" autocompletes the target url, as expected. Mozilla doesn't keep in either url bar or global history the originating urls (those redirecting to another location). Suggesting wontfix.

urlbar autocomplete is not a feature od session history. It is associated to global history.

over to hewitt, senor autocomplete

"History->Global. The link you provided redirects to http://login.europe.yahoo.com/config/mail?.intl=se whirch is saved in location bar history, instead of mail.yahoo.se. Hense, only by typing "login" autocompletes the target url, as expected. Mozilla doesn't keep in either url bar or global history the originating urls (those redirecting to another location). Suggesting wontfix." But it worked before (a few days/weeks ago)... FWIW, I still think it should be fixed ;-)

Also seeing this on slashdot.org (with 200112903, used to work in older builds). Entering "www.sla" would autocomplete; now, since the URL is actually "http://slashdot.org", mozilla will not complete "www.sla" to "www.slashdot.org". Suggesting higher severity (normal), as *MANY* users will be confused by this behaviour.

Even worse, Hotmail shows the same behavior! This will indeed confuse MANY users... Changing severity to Normal.

This is not an autocomplete bug, history should be storing these urls but it is not

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

Not platform specific. Maybe dependent on bug 48202 but not sure.

We do store these redirect urls but they're just hidden in the UI, right? We need to ensure that autocomplete still matches against them.

alec/hewitt: I think we should still match against hidden urls even if we don't show them in the history window. IE hides redirected urls just like us but their autocomplete still matches against them. It would be a shame to make users who check their e-mail every day type `lc2.law13' to autocomplete hotmail.com.

Comment on attachment 68735 [details] [diff] [review] patch? no! if we do this then mozilla will be blocked from MSN, among other sites. Here's what we should be doing: - add a new mork column, "typed" (like "hidden") which determines if the row was entered on the URL bar. - add an API to nsIBrowserHistory to flag a url as "typed" - when a user hits enter in the URL bar, turn the text entered into a url, and then call that nsIBrowserHistory option - fix the autocomplete enumerator to check if hidden urls are also "typed" - if so, then return them.

I should add that I really am excited about getting this bug fixed - another common one is amazon.com - you'll note that no matter how many times you visit amazon, "http://www.amazon.com/" is never in the autocomplete.

Umm...okay...but what does this mean: > no! if we do this then mozilla will be blocked from MSN, among other sites. Why does this make us be blocked?

because 304 redirects are sometimes used to obscure hidden information like passwords, and such. We cannot ever display the results of 304 redirect to users on screen. Yes, I know they are stored unencrypted on the filesystem, but certain sites (Such as MSN) will block clients that are known to display 304 redirected urls on the screen. This is why to this day Netscape 6.0-6.2 is blocked from MSN.

I think you don't mean 304 Not modified response... (Perhaps 302, 303 or 307.) I think that MSN is really really broken if they send passwords in cleartext in GET requests. They shouldn't do that and they shouldn't block browsers that autocomplete to original adresses of temporary redirects. So they should use POST method to send passwords (I don't say that this is perfectly secure :-)) and generate 303 response on that request if they want. But the browser should autocomplete to the ORIGINAL address. I wouldn't mind if I couldn't rather autocomplete to the destination address than to the original address (esp. on 307 response).

yes, we KNOW that, but all other browsers hide 304 redirects (or whatever, I was told they were 304's, I'm just interpreting a REDIRECT flag that comes in from necko) from global history, and I believe it is the right thing to do, because I think there are lots of legitimate uses of 3xx redirects that would otherwise pollute the global history UI with all sorts of garbage. What I'm suggesting doing is overriding the hide-the-304 behavior, but ONLY when a user has actually typed the url at the url bar.

I agree with alec, and on closer inspection, this is what IE does (only if I type in hotmail.com will it autocomplete it in the urlbar).

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

Cc'ing alec for sr (well, not really. but since he lost his mail, here's a reminder ;)

Comment on attachment 69156 [details] [diff] [review] patch cool, so the fixupURI thing will turn "amazon.com" into "http://amazon.com" or something similar? (just to confirm) sr=alecf

Comment on attachment 69156 [details] [diff] [review] patch r=hewitt

fixed.

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

reopening. as i noticed in bug 162325, we are not purging sites at all, so the pre-redirect site will not get purged and will appear to work. This purging should happen in nsGlobalHistory::MatchExpiration() at shutdown. on the branch, redirected sites are purged so they don't show up in autocomplete (chimera bug 159013).

this patch checks the "num visited" column when purging a typed and hidden url from the history. if it has been visited and it's typed and hidden, it's a redirect and we should keep it. if it hasn't been visited, it's an invalid typed site. looking for r/sr for trunk. i've already landed this on the chimera branch.

Nav triage team: nsbeta1+/adt3

Mike, Would you be able to drive your patch to checkin?

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

this is broken again. http://mail.yahoo.com and http://www.espn.com don't work as of build 2003051908, on lunix or windows. please, please fix.

please, please, offer up a patch.

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

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

Adding regression and 4xp keywords.

Forgot to add top100 keyword also (for Amazon).

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

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

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

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

This WORKSFORME with linux trunk 2005042102. Is anyone still seeing this bug?

You're right, this WFM as well using a 20050417 Windows Firefox build. Resolving worksforme, please reopen or comment if someone can find a way to reproduce.