Closed Bug 461483 Opened 16 years ago Closed 14 years ago

Ignore 'www.' when searching in the the awesome bar

Categories

(Firefox :: Address Bar, enhancement)

Product:
Firefox
Component:
Address Bar
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 4.0b1

People

(Reporter: webmaster, Assigned: Mardak)

References

Details

Attachments

(1 file, 1 obsolete file)

v1.1
4.86 KB, patch
mak
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 MultiZilla/1.8.3.4e SeaMonkey/1.1.12
Build Identifier: 

I tried setting browser.urlbar.matchBehavior to 3 to make it only search from the beginning.

That works pretty except in the following cases.

Typing "some" will not match "www.somesite.com", but will "somesite.com"
It will also match "someusername:password@unrelatedsite.com"

I'd like to suggest either as a change to setting "3" or as a possible additional "4", that it not count the "www." as part of what it matches, and that it also not count login information in what it matches, but still goes from the beginning.


Reproducible: Always
(I would like to add that this was part of what I had intended when I filed: https://bugzilla.mozilla.org/show_bug.cgi?id=461428 )
That would be great addition.
Blocks: 468326
Possibly an option to make it match start of words as in option 2, but only in links?
There's a separate preference to match only urls. In 3.2 trunk builds, it's browser.urlbar.default.behavior.
There are other prefixes which were ignored before, and should still be ignored. 'ftp.' springs to mind.



This probably should block bug 451760
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
i still don't get it why after so many months no one actually "fixes" this problem, seriously, this "bug" solution probably is as easy as adding "www." to the part where the code checks for the "http://", i still use ff2 because of this, and i have a ton of friends in this exact same situation...

i even tried changing it myself, but i'm no ff dev so i'm not used to the code and its simply brain challenging looking for it...

what exactly is holding back the resolution of this problem?
I'm not particularly interested in adding new behaviors for things that are not the default set of preferences, since this increases code complexity.  But I think a relevant issue is deciding if we want to match against anything in http://wwww by default.

Ed: If we ignore http://, is there a specific reason to not also ignore "www" at the start of domains?

In terms of login information, I can imagine users wanting to search against this (it might be more memorable than the domain).

cc'ing Limi since he is doing a lot of design work on the location bar at the moment.
Summary: Ignore 'www' and login info when browser.urlbar.matchBehavior set to match beginning → Should we ignore 'www' when searching in the the awesome bar?
I asked the same thing about stripping www. early last year in bug 424717 comment 6.

I remember stripping off www. in my original implementation, but ended up just only doing protocols.

The only major thing I ran into with my quick testing was that typing "www." wouldn't match anything. So if you type "www.mozilla.com" it wouldn't find http://www.mozilla.com because internally it appears at "mozilla.com".

So then I added an additional prefix filter of "www.", so "www.moz" would search as if you typed "moz". But that was still kinda odd, but it's no different than what we do right now if you type "http://moz" and it searches as if you typed "moz".
>So then I added an additional prefix filter of "www.", so "www.moz" would
>search as if you typed "moz". But that was still kinda odd, but it's no
>different than what we do right now if you type "http://moz" and it searches as
>if you typed "moz".

That seems reasonable to me, after you have typed in www you really haven't provided any useful information, so in my opinion failing to match anything still makes sense.  The current results are accurate in that they are the sites you visit most often, but without knowing that or realizing it, it feels kind of random.
Plus it ruins the matching of websites that start with "w", since it's showing all websites URL's that happened to have www. attached to them also.
Does anyone know what file in the source files handles these location bar operations?
(In reply to comment #13)
> Does anyone know what file in the source files handles these location bar
> operations?

i would appreciate this too, i'm sick of waiting for such a simple solution that most probably wont ever come... i want to move on to ff3, but i've been stuck with ff2 forever...

just point me the file(s), i would love you for the rest of the days for it
Attached patch v1 (obsolete) — — Splinter Review 
per faaborg's comment 11
Great Edward. So do you think we'll see that change included in the next update?
Depends on: 455555
could someone tell me why is this patch still not present on the official builds?

i mean, do we really have to wait YEARS for it?

i don't know how are these patches approved but seriously, something this simple shouldn't take so long to be accepted... this is still the only reason i have to build firefox myself...
So what's going on with this? It's been ages and Edward even posted the fix for it. This is a pretty big dysfunction in the operation of Firefox for the many people who don't like the new "Awesome Bar"... Could someone on the Firefox team please take 5 minutes out of their life to add the 4 extra lines of code to Firefox's trunk?
His patch needs to be reviewed (which he can request), but would need a test (which he added a TODO comment for).
Please can someone make Firefox URL bar behave like every other browser out there? This is Usabililty 101 for crying out loud.

(In reply to comment #18)
> Could someone on the Firefox team please take 5 minutes
> out of their life to add the 4 extra lines of code

This is apparently "adding to code complexity" which is apparently a big no-no. :)
(In reply to comment #20)
> Please can someone make Firefox URL bar behave like every other browser out
> there? This is Usabililty 101 for crying out loud.
Please see comment 19 where I *just* indicated how this can be taken in the product.
(In reply to comment #21)
> Please see comment 19 where I *just* indicated how this can be taken in the
> product.

After a year, that would indeed be Awesome.
(In reply to comment #22)
> After a year, that would indeed be Awesome.
In all fairness, he knows what needs to be done to get this in the tree.  Given that the bug isn't assigned to him indicates that he may not care to drive this to the finish.
Yes but I see these long-outstanding bugs here a lot.
Isn't the idea that *anyone* can take up the fix?
If everyone assumes "he will get to it", it'll never get done.
And this one is pretty important to the user experience.
(In reply to comment #24)
> Yes but I see these long-outstanding bugs here a lot.
> Isn't the idea that *anyone* can take up the fix?
> If everyone assumes "he will get to it", it'll never get done.
> And this one is pretty important to the user experience.
It's not assigned to anyone, so yes, anyone can finish this up and drive it in.
Attached patch v1.1 — — Splinter Review 
Unbitrotted and added tests.

Your lucky day! I happened to push almost 2000 changesets to mozilla-central today, so I feel like one more couldn't hurt! ;)
Assignee: nobody → edilee
Attachment #390600 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #453663 - Flags: review?(mak77)
Great to hear Edward, thanks a bunch :)
Comment on attachment 453663 [details] [diff] [review]
v1.1

>Bug 461483 - Should we ignore 'www' when searching in the the awesome bar?

I hope you'll push with a more appropriate title than a question :)

>diff --git a/toolkit/components/places/src/SQLFunctions.cpp b/toolkit/components/places/src/SQLFunctions.cpp
>--- a/toolkit/components/places/src/SQLFunctions.cpp
>+++ b/toolkit/components/places/src/SQLFunctions.cpp
>@@ -89,16 +89,18 @@ namespace places {
>       CopyUTF8toUTF16(aURISpec, _fixedSpec);
> 
>     if (StringBeginsWith(_fixedSpec, NS_LITERAL_STRING("http://")))
>       _fixedSpec.Cut(0, 7);
>     else if (StringBeginsWith(_fixedSpec, NS_LITERAL_STRING("https://")))
>       _fixedSpec.Cut(0, 8);
>     else if (StringBeginsWith(_fixedSpec, NS_LITERAL_STRING("ftp://")))
>       _fixedSpec.Cut(0, 6);
>+    if (StringBeginsWith(_fixedSpec, NS_LITERAL_STRING("www.")))
>+      _fixedSpec.Cut(0, 4);

newline before the if please, I want that it's clear is not a typo the fact this is not an else if.

>diff --git a/toolkit/components/places/src/nsPlacesAutoComplete.js b/toolkit/components/places/src/nsPlacesAutoComplete.js
>--- a/toolkit/components/places/src/nsPlacesAutoComplete.js
>+++ b/toolkit/components/places/src/nsPlacesAutoComplete.js
>@@ -575,16 +575,18 @@ nsPlacesAutoComplete.prototype = {
>     let uri = aURIString;
> 
>     if (uri.indexOf("http://") == 0)
>       uri = uri.slice(7);
>     else if (uri.indexOf("https://") == 0)
>       uri = uri.slice(8);
>     else if (uri.indexOf("ftp://") == 0)
>       uri = uri.slice(6);
>+    if (uri.indexOf("www.") == 0)
>+      uri = uri.slice(4);

ditto

looks good, let's try to make the beta for feedback.
Attachment #453663 - Flags: review?(mak77) → review+
Flags: in-testsuite?
http://hg.mozilla.org/mozilla-central/rev/5ee6584ed786
Strip out www. from found urls and the query after already stripping off http://, etc. Update tests now that www. can't be matched.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a6
Summary: Should we ignore 'www' when searching in the the awesome bar? → Ignore 'www.' when searching in the the awesome bar
Is there any standard concerning the www subdomain? Are there any other default subdomains in this standard?
Thank Dog, nearly 2 years and it's finally fixed! This was one of the reasons I'm still using FF2. Will it be available in the next release?
With the proposed changed, what would happen if someone typed 'http://www.', 'https://www.' or 'ftp://www.'?
The same as what happens currently when you type 'http://'
(In reply to comment #31)
> Thank Dog, nearly 2 years and it's finally fixed! This was one of the reasons
> I'm still using FF2. Will it be available in the next release?

In all likeliness, it will be available in Firefox 4.0.
(In reply to comment #34)
> In all likeliness, it will be available in Firefox 4.0.

Hm, in that case can we squeeze in 575171 as well? :)
What happens if I actually want to match "www.example.com" and not some other host in the "example.com" domain?
Depends on: 585971
You won't be able to match that one specifically. But it is very unlikely that someone every needs to match "www.". Thus it's more logical to have it changed to what has been proposed.
I use this other browser called Firefox 2. There are many improvements over Firefox 3, including correct url matching behaviour. Give it a try, you'll never go back to FF3 again.
(In reply to comment #37)
> You won't be able to match that one specifically. But it is very unlikely that
> someone every needs to match "www.". Thus it's more logical to have it changed
> to what has been proposed.

Well, I need to. Case in point: I have around 10000 URLs for *.uni-osnabrueck.de in moz_places (places database), out of these are 189 for www.uni-osnabrueck.de. These will effectively no longer autocomplete for me (buried in other unrelated matches). That's just 2%, but it is significant for me.
http://www.uni-osnabrueck.de
and
http://uni-osnabrueck.de

lead to the exact same page. So you would just start typing "u" instead of "w".

It's extremely rare for a website to not have the www. be the same page as it without the www.
doesn't look like there is much value in seraching for a part of the host without specifying further search terms... you will most likely match on title or on the path/query string. even if that would match on www you would still have to specify other search terms to restrict the results since you have so many www.yourdomain results.
(In reply to comment #40)
> [...] So you would just start typing "u" instead of "w".

Hm, what difference does that make? Typing "uni" will also match all host in the uni-osnabrueck.de domain (of which there are _many_, like blogs.uni-osnabrueck.de, webmail.rz.uni-osnabrueck.de, www.alumni.uni-osnabrueck.de just to name a few). So the page I want to match is somewhere around position 30 in the autocomplete dropdown, hidden behind lots of entries that do not match what I actually typed...

> It's extremely rare for a website to not have the www. be the same page as it
> without the www.

Yes, but that does not help me here in any way (see above).

(In reply to comment #41)
> doesn't look like there is much value in seraching for a part of the host
> without specifying further search terms... you will most likely match on title
> or on the path/query string. even if that would match on www you would still
> have to specify other search terms to restrict the results since you have so
> many www.yourdomain results.

If that is true, why does autocomplete match on the host in the first place? Note that this bug was reported for the case "browser.urlbar.matchBehavior = 3", where autocomplete will not even match on the path or query string (unless you type most of the URL first).

Typing "www.uni" will definitively not match on the path/query string here (I'm used to doing that, or at least, I was). This used to restrict matches to URLs from http://www.uni-osnabrueck.de for me, and after that I could either directly select a URL from the dropdown or add further search terms. That use case is completely broken now for such URLs.

Would it be possible to give results a higher ranking that match what I typed (in full, without stripping the "www.")?
I don't think you're understanding how this fix works.

Firstly, it's not going to make matching blog.uni or webmail.rz.uni stop working. When you type "u", those ones aren't going to show up. Because they don't start with "u", they start with "b" and "w".

All this fix is doing is ignoring specifically the www. prefix of url's when matching, as www provides no extra needed information ever really.

So when the change comes into effect, all YOU will be doing instead of pressing "w" like you do now, is typing "u". That's the only effect it's going to have on you.
(In reply to comment #43)
> I don't think you're understanding how this fix works.

I understand that very well.

> Firstly, it's not going to make matching blog.uni or webmail.rz.uni stop
> working. When you type "u", those ones aren't going to show up. Because they
> don't start with "u", they start with "b" and "w".

"Starting with" is not relevant here, but "contains anywhere in the URL or title", since the behaviour was changed for all settings of browser.urlbar.matchBehavior, including the default of 1 (match anywhere, prefer word boundaries). See comment #9.

> All this fix is doing is ignoring specifically the www. prefix of url's when
> matching, as www provides no extra needed information ever really.

That is not true. It is distinguishing www.uni-osnabrueck.de from blogs.uni-osnabrueck.de. Typing "u" will match both with the default settings.
"That is not true. It is distinguishing www.uni-osnabrueck.de from
blogs.uni-osnabrueck.de. Typing "u" will match both with the default settings."

The only reason it's distinguishing between www.uni and blog.uni in that situation is because blogs.uni-osnabrueck.de... doesn't contain a "W" anywhere in the URL. But if you type "u", it's going to bring up any address with a "u" in it, in order of view frequency, including blogs.uni and www.uni in the same results.

So basically the complaint is that you can no longer make that specific url show up by using "w" because it contains no W's in the actual address.

But you could easily resolve this by setting it to only match from the beginning of the URL. So when you type "b", it brings up blogs.uni, type "u" it brings up www.uni, and so on.
(In reply to comment #45)
> The only reason it's distinguishing between www.uni and blog.uni in that
> situation is because blogs.uni-osnabrueck.de... doesn't contain a "W" anywhere
> in the URL. But if you type "u", it's going to bring up any address with a "u"
> in it, in order of view frequency, including blogs.uni and www.uni in the same
> results.

Note that I was just quoting the "w" from your post, I'm not actually doing that.

> So basically the complaint is that you can no longer make that specific url
> show up by using "w" because it contains no W's in the actual address.

No, my problem is that typing "www.uni" will no longer properly restrict matches to "www.uni-osnabrueck.de" (and instead match anything that contains "uni"), and typing "www.moz" will no longer restrict matches to "www.mozilla.org" (vs. URLs from bugzilla.mozilla.org for example). Typing just "w" or "u" was your example.

> But you could easily resolve this by setting it to only match from the
> beginning of the URL. So when you type "b", it brings up blogs.uni, type "u" it
> brings up www.uni, and so on.

But I _want_ the search terms to match anywhere in the URL or title, generally. I understand that the fix here is useful for the case of browser.urlbar.matchBehavior = 3, and I'm not contesting that, but that's not how I am using autocomplete. If I'm the only person hit by this change, I should probably stop complaining and just patch my Firefox build. I just fear that the assumption that "after you have typed in www you really haven't provided any useful information" is wrong for more people.
Elmar, you're not alone.
To make it clear by using my own words (so maybe Kakkoii et al. will understand): I have a number of URLs in bookmarks & history which include a www. prefix. I have other URLs for the same domains where the www. prefix is absent. How can I specify a URL for autocomplete in such way that it will match www.mozilla.org (of which I have only a few) but not bugzilla.mozilla.org, addons.mozilla.org, developer.mozilla.org or wiki.mozilla.org (of all four of which I have quite a lot)? (and OTOH if I type just "mozilla" I want to complete to all five of them, and also to www.mozilla.com and kb.mozillazine.org, and hope to get the most recent ones of them all)
Does this newsgroup discussion have to continue in this fixed bug for still a long time? You MUST either move it to a new bug or move it the usability newsgroups, or just notice that to match www.mozilla you can simply type "www mozilla". This could be different from the behavior you're used, but that usually just require to have patience and give you time to try/learn the new behavior. But really please move this OMGCHANGE discussion in a more proper place.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: