Closed Bug 424717 Opened 16 years ago Closed 16 years ago

Location bar autocomplete should be willing to complete to a URL with a different protocol

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.1a2

People

(Reporter: raccettura, Assigned: Mardak)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fixed by bug 424509])

Attachments

(2 files, 2 obsolete files)

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.
Attached image screenshot of v1
Blocks: 424509
Blocks: 405745
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]
Attached patch v1 (obsolete) — Splinter Review
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: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
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]
Attached patch v1.1 (obsolete) — Splinter Review
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.
Attachment #311617 - Attachment is obsolete: true
Attachment #311795 - Flags: review?(dietrich)
Attachment #311617 - Flags: review?(dietrich)
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.
Attachment #311795 - Flags: review?(dietrich)
No longer blocks: 424509
Depends on: 424509
No longer depends on: 422698
Whiteboard: [has patch][need dietrich review][need bug 422698][fixes bug 424509] → [has patch in bug 424509]
Attached patch testcase v1Splinter Review
Attachment #311795 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/index.cgi/rev/b50d74de574b
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
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
Blocks: 485953
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.
Depends on: 723622
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.

Attachment

General

Creator:
Created:
Updated:
Size: