Closed Bug 424717 Opened 12 years ago Closed 12 years ago
Location bar autocomplete should be willing to complete to a URL with a different protocol
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.
Component: Places → Location Bar and Autocomplete
QA Contact: places → location.bar
Summary: Places should be protocol unaware http/https → Location bar autocomplete should be willing to complete to a URL with a different protocol
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.
Whiteboard: [Fx2-parity][has patch][need dietrich review][fixes bug 424509]
Version: unspecified → Trunk
Depends on: 422698
Whiteboard: [Fx2-parity][has patch][need dietrich review][fixes bug 424509] → [Fx2-parity][has patch][need dietrich review][need bug 422698][fixes bug 424509]
Fix and testcase! I'll even land an extra testcase with bug 424509. ;)
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #311617 - Flags: review?(dietrich)
Does this build fix the issue for you? https://build.mozilla.org/tryserver-builds/2008-03-25_22:firstname.lastname@example.org/ 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
Whiteboard: [Fx2-parity][has patch][need dietrich review][need bug 422698][fixes bug 424509] → [has patch][need dietrich review][need bug 422698][fixes bug 424509]
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [has patch in bug 424509] → [fixed by bug 424509]
Target Milestone: --- → Firefox 3.1a2
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
Status: RESOLVED → VERIFIED
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.
You need to log in before you can comment on or make changes to this bug.