From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test10 i686; en-US; m18) Gecko/20001211 BuildID: 2000121112 When the autocomplete in the navigation toolbar learns an address with http://, it won't present it as an alternative for an address without http://. The opposite is also true. Reproducible: Always Steps to Reproduce: 1. Make autocomplete learn an address starting with http:// 2. Start typing the same address without the leading http:// Actual Results: It didn't present the URL it learned in step 1 as an alternative Expected Results: Munge the URL (i.e. chop the leading http://) and present it as an alternative. In the opposite case, add a leading http:// and present it as an alternative. If the guessing rules say something else (like ftp://) should be used, it should be used instead of http:// above. Be careful with border cases (if the saved url starts with "ftp.a" and the user starts typing "http://ftp.a" it shouldn't match, for instance).
i think this is reported, however could not find it. Over to xpapps
could this be a dup of bug 51910?
Nope. Bug 51910 is about autocomplete doing too much; this one is about autocomplete doing too little.
This is a RFE I am going to go ahead and mark this as NEW so someone can decide which one to choose. Too Much too little.
The patch attached to 60678 addresses this issue.
nav triage team: Marking nsbeta1-, won't look at this for beta1.
making this depend on 60678 per Radha's comments. Feel free to dupe this though.
See also bug 63421.
This is probably fixed with one of the earlier patches. Markign fixed so that QA can verify. Please re-open if not.
I have verified it with 2001022808. I guess I have enough access to mark it as VERIFIED, since I'm the original reporter.
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.