Last Comment Bug 765337 - www prefix is added to URL that loads after accepting inline-autocomplete suggestion
: www prefix is added to URL that loads after accepting inline-autocomplete sug...
Status: RESOLVED FIXED
: regression
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: All All
: -- normal with 11 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Marco Bonardo [::mak]
Mentors:
: 790175 791603 795027 847829 (view as bug list)
Depends on: 769348
Blocks: 659437 720081
  Show dependency treegraph
 
Reported: 2012-06-15 12:25 PDT by Marat Tanalin | tanalin.com
Modified: 2013-06-11 02:59 PDT (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Marat Tanalin | tanalin.com 2012-06-15 12:25:21 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120612164001

Steps to reproduce:

In Firefox 14 beta, a weird behavior has appeared. "autoFill" feature adds "www." prefix to URL in location bar though neither browser's history nor bookmarks do contain corresponding URL with "www." prefix.

If I start to type, for example, "stack", then "stackoverflow.com" is automatically placed into location bar. It's correct.

But then, if I just press "enter" key, "www.stackoverflow.com" (with "www." prefix) is for some reason starting loading instead of "stackoverflow.com" that has been shown in location bar when I've started typing and pressed "Enter" key.

But if I start to type "stack", and then press "down-arrow" key once (thus choosing [from the URL list suggested by Firefox] _same_ URL as has been suggested by autoFill autocomplete) and _then_ press "Enter" key, "stackoverflow.com" (without "www." prefix) is opened as expected ("www." prefix is not prepended to the URL).

Neither my history nor bookmarks do contain the URL with "www." prefix. The "www." prefix is apparently added wrongly by autocomplete mechanism of Firefox when using autoFill feature (that's probably what's called inline autocomplete). Tested multiple times (with different URLs affected by the bug) in Library window opened via "Ctrl+Shift+H" keyboard shortcut.

The only workaround I've found is to "forget the site" with corresponding context menu-item of one of search/filter results in Library window. But that's undesirable and annoying since cookies are deleted too, and I'm forced to relogin to all sites that have been worked-around this way.

This bug is reproduced in both latest Firefox 14 beta (20120612164001) and Nightly (20120615042503).


Actual results:

After pressing "Enter" on inline-autocompleted URL without "www." prefix, "www." prefix is automatically added to the URL though original URL from history/bookmarks does not contain "www." prefix.


Expected results:

"www." prefix should not be automatically added to URL that actually does not contain it.
Comment 1 Matt Brubeck (:mbrubeck) 2012-06-15 12:46:23 PDT
Possibly a regression from bug 720081.
Comment 2 Yann Brelière 2012-06-15 15:07:38 PDT
It happens all the time when I type "tra" and it auto-completes to "translate.google.com", it seems it loads instead "https://www.translate.google.com" (but I don't see it), which redirects to "https://www.google.com/".
It doesn't happen for example for maps.google.com or others.
Comment 3 Marco Bonardo [::mak] 2012-06-18 12:03:57 PDT
Your history contains a www. entry, even if you didn't explicitly type it, it's likely some stackoverflow page you visited redirects to it, that's cause there's no way we may try to add www. unless a www. entry exists at all in history.
Comment 4 Marat Tanalin | tanalin.com 2012-06-18 15:54:43 PDT
(In reply to comment #3)

As I've said in the bug description, searching in Library by "http://stackoverflow.com/" window shows 0 (zero) results. Also, inline-autocompleted URL and URL loading after pressing "Enter" should be identical, but currently they are not.
Comment 5 Marat Tanalin | tanalin.com 2012-06-18 15:56:38 PDT
Oops, "http://stackoverflow.com/" in comment 4 should be read as "www.stackoverflow.com" (that was just a typo caused by copy-pasting from location bar).
Comment 6 Marco Bonardo [::mak] 2012-07-03 09:18:03 PDT
(In reply to Marat Tanalin | tanalin.com from comment #4)
> As I've said in the bug description, searching in Library

That's not enough, not all results are shown in the Library, some considered less important (like redirects) are omitted. What I meant is that there is a "www." entry in the database.
Comment 7 Marat Tanalin | tanalin.com 2012-07-03 16:28:28 PDT
(In reply to comment #6)
> not all results are shown in the Library, some considered
> less important (like redirects) are omitted. What I meant is that there is a
> "www." entry in the database.

Thanks. Anyway, even there is a "www." entry in the database, it's completely wrong to show it in first place of autocomplete since the entry is _not_ (in fact far from) most often accessed URL matching typed URL.

If URL is omitted in Library, then it obviously should be omitted in autocomplete too and definitely should not be shown in first place of autocomplete, moreover www should not be added on _loading_ phase while it has _not_ been shown on _autocomplete_ phase thus totally confusing user.

Inline-autocomplete algorithm is broken currently. IMO, inline autocomplete should just use first of results of regular (not inline) autocomplete that works correctly.
Comment 8 Petteri 2012-07-17 13:15:00 PDT
Just upgraded to official firefox 14 and came across this bug. It breaks several websites.
Comment 9 Brian Marshall 2012-07-22 23:39:49 PDT
(In reply to Marco Bonardo [:mak] from comment #3)
> Your history contains a www. entry, even if you didn't explicitly type it,
> it's likely some stackoverflow page you visited redirects to it, that's
> cause there's no way we may try to add www. unless a www. entry exists at
> all in history.

IMO, a single once-visited entry in the history shouldn't alter the behavior of a feature that's supposed to select the most-visited result of a search, especially with no visible signs of this until *after* you press enter and start loading the website. Is there a reason why the auto-complete algorithm is thinking "does www.[domain] appear anywhere in the history" instead of "is www.[domain] the most-visited form of this website in the history"?

It'd be less of an issue if the location bar showed any indication that this is going to happen. As it is, you type in "do", see it auto-completed to "domain.com", and even notice that the top entry in the awesome bar is "domain.com" (with no wwws present in any of them), and still be whisked away to a domain that you never intended to visit after pressing enter.

This seems like a disregard of the principle of least astonishment.
Comment 10 Marat Tanalin | tanalin.com 2012-07-23 04:14:46 PDT
Steps to 100% reproduce the bug (reproducible both in latest Firefox 15 beta and Firefox 17 nightly):

1. Type-in "stackoverflow.com" (without "www." prefix) in location bar of Firefox 14+, then press "Enter" key. Close the tab opened.

2. Type-in "www.stackoverflow.com" (with "www." prefix) in location bar, then press "Enter". Close the tab opened.

3.1. Type-in "stack" (without "www." prefix) in location bar. Inline autocomplete shows "stackoverflow.com" (without `www.` prefix).

3.2. Press "Enter". "www." prefix is wrongly added to the URL shown in location bar before pressing "Enter" (shown correct "stackoverflow.com", but loaded wrong "www.stackoverflow.com" instead). "www."-containing URL is loaded and then server-side redirect happens, and finally correct non-www URL is loaded. This creates unneeded delay and worse user experience due to lower perceived page-loading speed.

Expected results:

A. Browser should load _exactly_ URL that has been shown as result of inline autocomplete before pressing "Enter".

B. "www." prefix should not be added neither before pressing "Enter" key nor after that as long as user has not typed-in "www." _explicitly_ and there are no browser-history entries that do not contain "www. + typed-in URL part".

C. "www." should only be there if it has been typed-in _explicitly_ by user AND browser history has an entry that contains "www. + typed-in URL part". In such case, "www." should be shown in location bar as result of inline autocomplete _before_ user pressed "Enter", NOT just added after pressing "Enter".
Comment 11 Marat Tanalin | tanalin.com 2012-07-23 04:27:48 PDT
It seems an unneeded negation has been added accidentally in penultimate paragraph of my comment 10. Instead, it should be read as (the whole comment should be clear enough anyway, but fixing it just in case):

  B. "www." prefix should not be added neither before pressing "Enter" key
  nor after that as long as user has not typed-in "www." _explicitly_ and
  there are no browser-history entries that contain "www. + typed-in URL part".
Comment 12 Marco Bonardo [::mak] 2012-07-24 05:51:43 PDT
the opposite case may be true, a non www. domain may redirect to the www. ones, so it's likely matter of what is more common on the Web, though I don't see a perfect solution for all existing cases.
Comment 13 mozilla 2012-08-17 10:11:23 PDT
I can confirm this bug too. I'm also having trouble with appending www to translate.google.com (I can assure that I didn't type www.translate.google.com neither have it in cache or history). More over I have passwords saved for some sites like "domain.com" but adding www makes different domain "www.domain.com" for which password manager has no stored passwords.
Comment 14 Matthias Versen [:Matti] 2012-09-11 07:47:16 PDT
*** Bug 790175 has been marked as a duplicate of this bug. ***
Comment 15 Loic 2012-09-17 05:25:24 PDT
*** Bug 791603 has been marked as a duplicate of this bug. ***
Comment 16 Matthias Versen [:Matti] 2012-09-27 14:01:32 PDT
*** Bug 795027 has been marked as a duplicate of this bug. ***
Comment 17 Johnathan Nightingale [:johnath] 2012-11-01 07:10:57 PDT
I agree that surprising people with URL changes is poor behaviour, and has the unfortunate side effect of potentially breaking things (I think 'www' is reasonably universal as a safe prefix, but the translate.google case above feels like a good example of "should never need www").

From what I gather, either:

a) Marco's right and each user above has a 'www.X' entry in their places history somewhere. This is testable with some scratchpad code that the reporters can run in chrome context to verify. If true, it suggests we need to change our auto-fill so that these hidden-and-surprising entries stop breaking our behaviour.

b) Marco's wrong and some of the people here are having www prepended *without* a corresponding history entry, in which case we should stop doing that.

Either way, this is a real bug because we're not doing what our users want, and if we can't be smart-and-helpful, we should avoid being 'helpful' at all (c.f. MS Office clippy).

Let's start by testing (a). Do we have a volunteer from the audience to work with Marco to get some diagnostics?
Comment 18 Marco Bonardo [::mak] 2012-11-01 08:17:16 PDT
(In reply to Johnathan Nightingale [:johnath] from comment #17)
> a) Marco's right and each user above has a 'www.X' entry in their places
> history somewhere. This is testable with some scratchpad code that the
> reporters can run in chrome context to verify. If true, it suggests we need
> to change our auto-fill so that these hidden-and-surprising entries stop
> breaking our behaviour.

Just searching history should be enough, unfortunately there's a bug currently that makes searches not returning everything (Bug 773982) and I'll try to fix that shortly.

> b) Marco's wrong and some of the people here are having www prepended
> *without* a corresponding history entry, in which case we should stop doing
> that.

We could produce a restartless add-on to verify this). Actually may be a good idea to have an add-on able to tell "where does this address come from" for debug purposes, it may tell "you have X visits to this page, or Y bookmarks in this path".
Comment 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-11-01 11:30:11 PDT
Presumably these entries are there because people may have accidentally hit Cmd/Ctrl+Enter after having typed "translate.google.com", pre-bug 673528 (i.e. in Firefox 6 and earlier)? That would result in us loading "www.translate.google.com".

When these entries do exist, they almost certainly don't have more than a visit or two recorded, right? Compared to the accompanying "valid" entry that would have many more, presumably. Can we use that to filter out the bogus entries from triggering this behavior?
Comment 20 Marco Bonardo [::mak] 2012-11-02 06:03:11 PDT
any additional filter is a nontrivial amount of work (and IO), thus the current filters are really simple.
Comment 21 Simon Waldman 2012-12-03 05:00:07 PST
I'm currently running Aurora, and am happy to test things if it will help to get this resolved.

I see this behaviour with Livejournal / Dreamwidth users' subdomains, which do not work if a "www." is prepended. If I have once added a www by mistake, thus adding that to my history, I will not be able to visit that page again until I have manually removed it from the history.
Comment 22 Marco Bonardo [::mak] 2013-02-11 06:05:47 PST
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #19)
> Presumably these entries are there because people may have accidentally hit
> Cmd/Ctrl+Enter after having typed "translate.google.com", pre-bug 673528
> (i.e. in Firefox 6 and earlier)? That would result in us loading
> "www.translate.google.com".

If it was in Firefox 6, I doubt they can still be there, the avg history size is 6m-1y

> When these entries do exist, they almost certainly don't have more than a
> visit or two recorded, right? Compared to the accompanying "valid" entry
> that would have many more, presumably. Can we use that to filter out the
> bogus entries from triggering this behavior?

There is no clear rule about how to proceed here, we may for example consider just the last 10 visits, though that would only partially alleviate the problem, cause the mistake entry could be there.
Or we may consider the most frecent entry, I could investigate if this would be a perf hit or not.
Comment 23 Marco Bonardo [::mak] 2013-04-12 05:05:24 PDT
*** Bug 847829 has been marked as a duplicate of this bug. ***
Comment 24 gima 2013-04-16 03:56:35 PDT
(I verify this bug exists on Firefox 20.0.1 (Windows))


Here is a diagnosis of the problem:

* When an address with "www." prefix has been visited (example: www.google.com)
* then trying to visit a parent domain of that address
   (example: google.com)
* while leaving the autofilled slash "/" character selected
   (example: google.com/ with "/" selected)
* and pressing ENTER (mouse click on the go-button doesn't manifest this bug)
= the browser ends up issuing a request to the www subdomain
   (example: www.google.com)

(This bug doesn't manifest when "browser.urlbar.autoFill" is set to "false")
(Redirects used by google.com have nothing to do with this, tested)
(Observe the issued requests with Web Console, Wireshark, or something similar)


--- STEPS TO REPRODUCE THE BUG

1. HOSTS:
	# For testing, I had a webserver running on 127.0.0.1
	127.0.0.1		domain.tld
	127.0.0.1		www.domain.tld
	127.0.0.1		www2.domain.tld

2. Clear All History

3. about:config
  # Making sure cache and prefix-/suffix -fixups have nothing to do with this
  browser.fixup.alternate.enabled;false
  browser.cache.disk.enable;false
  browser.cache.disk.smart_size.enabled;false
  browser.cache.memory.enable;false

4. REPRODUCING THE BUG:
  - Type addresses into address bar (don't copy'n'paste):
    1. domain.tld
         Autofills: Nothing
         [Enter]
         -> GET http://domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Try to "poison" autofill with no subdomain)
    2. domain.tld
         Autofills: domain.tld/, where "/" is selected
         [Enter]
         -> GET http://domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Issues correct HTTP request)
    3. www2.domain.tld
         Autofills: Nothing
         [Enter]
         -> GET http://www2.domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Try to "poison" autofill with "www2" subdomain)
    4. domain.tld
         Autofills: domain.tld/, where "/" is selected
         [Enter]
         -> GET http://domain.tld/ [HTTP/1.1 200 OK 16ms]
         (Issues correct HTTP request.
          Apparently autofill can only be "poisoned" with "www" subdomain)
    5. www.domain.tld
         Autofills: www.domain.tld/, where "/" is selected
         [Enter]
         -> GET http://www.domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Try to "poison" autofill with "www" subdomain)
    6. domain.tld
         Autofills: domain.tld/, where "/" is selected
         [Enter]
         -> GET http://www.domain.tld/ [HTTP/1.1 200 OK 16ms]
         (Issues INCORRECT HTTP request.
         Tried to go to domain.tld, but browser decided to go to www.domain.tld)
    7. domain.tld
         Autofills: domain.tld/, where "/" is selected.
                    Press [END] to clear the selection
         [Enter]
         -> GET http://www.domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Issues INCORRECT HTTP request.
         Tried to go to domain.tld, but browser decided to go to www.domain.tld)
    8. domain.tld
         Autofills: domain.tld/, where "/" is selected.
                    Press [DELETE] to clear the selection
         [Enter]
         -> GET http://domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Issues correct HTTP request)
    9. domain.tld
         Autofills: domain.tld/, where "/" is selected.
		            Replace the selection by writing the "/" character.
         [Enter]
         -> GET http://domain.tld/ [HTTP/1.1 200 OK 0ms]
         (Issues correct HTTP request)
Comment 25 Ted Mielczarek [:ted.mielczarek] 2013-04-26 13:01:35 PDT
This bothers the hell out of me because it takes me to www.pastebin.mozilla.org all the time when I'm trying to go to pastebin.mozilla.org. I've deleted www.pastebin.mozilla.org from the Library view, but I can't get rid of it. :-(
Comment 26 Marco Bonardo [::mak] 2013-04-29 11:28:47 PDT
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #25)
> I've deleted www.pastebin.mozilla.org from the Library
> view, but I can't get rid of it. :-(

How did you found the entries to remove, by searching for "www.pastebin.mozilla.org"? do you have any bookmark pointing to the www version?
Comment 27 Marco Bonardo [::mak] 2013-06-11 02:59:08 PDT
The behavior changed in Bug 769348 so that www will only be suggested if all of the typed pages contain it. If the prefix is still suggested cause it was previously typed, it should now be enough to type once the unprefixed version to have the urlbar cope with that (where typed also means just edit once the suggested page to the non-www one).
Since the behavioral change, any issues with that should be filed in a new bug.

marking as fixed by Bug 769348.

Note You need to log in before you can comment on or make changes to this bug.