Say I type in 'g'. I see the following: http://www.google.com/ http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official https://www.google.com/reader/ What I'm looking for is: https://www.google.com/analytics If I press the down arrow once, I get google.com. I can append 'a', but nothing shows up. If places ignored the protocol for http/https, I'd get what I want with less effort. There might be a better "fix" for this, but it's a thought I've had for a little bit. Since I use a fair amount of https in my daily browsing I found that protocols can sometimes make places not as intelligent as it could be.

My paranoid side thinks the location bar should allow "http://..." to match http and https URLs, but "https://..." should only match https URLs. It probably reasonable to allow both, though.

If a search starts with a certain set of protocols, we could strip it off and search without the protocol. Only "http://" and "ftp://" ?

Jesse: At least in my opinion, that's the way it tends to work anyway. The https seem to be hard to access (relatively speaking) when you access a site over both http and https. My thought is that they should be on par.

Hmm - stripping the protocols sounds like something that might have unintended perf consequences, but I hear what you're saying in the case of analytics. I've been thinking about it myself, and I too use a lot of https sites, but have never hit this problem. I think it's because I don't often go to sites where I interact with both http and https in that intermixed way, outside of google. Or maybe because on the few that do, I choose more specific words (e.g. I get to my analytics page by typing "analyt"). I think that if we can get it for free, ignoring the protocol (at least for a certain set, and for searches that aren't already targetting the protocol - do people search for "ftp kernel.org"?) is, at very least, a worthwhile experiment. But I don't think it needs to block firefox 3 or anything, and I do think we will want to watch carefully for any performance hit, since it might mean a lot of string-fu.

The places where I hit this most are: - Work - Google - my blog If this really makes sense to do, I'm not sure. It's just an observation I've made based on my usage lately.

Should the list of "protocols" include "http://www" as well? Basically, if you have http://www.google.com/ in the location bar and hit down, it could act as if you searched for "google.com/"

(In reply to comment #6) > Should the list of "protocols" include "http://www" as well? Basically, if you > have http://www.google.com/ in the location bar and hit down, it could act as > if you searched for "google.com/" It's an interesting idea, but my impulse would be to keep things atomic - avoid scope creep. If ignoring protocols turns out to be a usability win, it will (presumably) be easy to tweak the list later.

Fix and testcase! I'll even land an extra testcase with bug 424509. ;)

Does this build fix the issue for you? https://build.mozilla.org/tryserver-builds/2008-03-25_22:08-edward.lee@engineering.uiuc.edu-title.tags.prefix.half/ Bug 424673 - Optimize AwesomeBar for correcting typos or removing terms that caused no results Bug 422277 - assertions in nsNavHistoryAutocomplete ("not a UTF8 string", etc.) Bug 422698 - different levels of URL decoding for address bar and autocomplete suggestions Bug 424717 - Location bar autocomplete should be willing to complete to a URL with a different protocol Bug 424509 - Location bar autocomplete favors "http://" over domain name starting with "h" Bug 418257 - Show what part of which tags match for urlbar autocomplete Bug 424216 - displaying filename/path instead of title for (unvisited?) bookmarks Bug 392143 - show keywords as url bar autocomplete choices Bug 249468 - Add all bookmark keywords to location bar autocomplete drop-down list Bug 395161 - Make it possible to restrict the url bar autocomplete results to bookmarks/history entries and match only url/title/tags Bug 420437 - Search and emphasize quoted strings with spaces Bug 423942 - "Clear List" in download manager should be "Clear Current List" during the search Bug 424557 - Allow AwesomeBar to default search only urls (or history/titles/bookmarks/tags) Bug 423718 - Use native platform colors for URLs in the location bar autocomplete, make the line between rows lighter Bug 424213 - URLs without corresponding title are displayed with a blank title (which isn't full-height) Bug 415190 - Autocomplete results can be incorrectly sized (clipped) Bug 414326 - Use DownloadUtils for software update downloads

Updated testcase and added http<->https<->ftp as the user could just as easily have a https site first in their history even if searching for "google" Searching for "google" happens to result in "https://www.google.com/" first, and pressing down then delete searches for other google sites.

Seems to work for me. Makes those domains with mixed http/https usage seem easier to access. I guess the next big question is if deciding if comment #1 is a good idea, or just paranoia.

Comment on attachment 311795 [details] [diff] [review] v1.1 I'll land just the testcase when it's okay to do so.

Verified FIXED using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080814041610 Minefield/3.1a2pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/20080814020606 Minefield/3.1a2pre -and- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080814020600 Minefield/3.1a2pre

Is there any way to disable this fix? Perhaps a configuration parameter? I have a number of sites that I access via https. When I start the URL with https:, I expect these sites to show in the matched list, but my results are full of http: URLs and the actual URSs that match are nowhere to be found. I was going to file a bug saying that the location bar ignores the protocol when matching URLs, but after much digging eventually found this bug.

Andre, I filed bug 723622 on one possible solution.