Closed Bug 765337 Opened 12 years ago Closed 11 years ago

www prefix is added to URL that loads after accepting inline-autocomplete suggestion

Categories

(Firefox :: Address Bar, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mtanalin, Unassigned)

References

Details

(Keywords: regression)

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.
Blocks: 659437
Component: Untriaged → Location Bar
Possibly a regression from bug 720081.
Blocks: 720081
Keywords: regression
OS: Windows 7 → All
Hardware: x86_64 → All
Version: Trunk → 14 Branch
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.
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.
(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.
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).
(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.
(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.
Just upgraded to official firefox 14 and came across this bug. It breaks several websites.
(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.
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".
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".
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.
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.
Version: 14 Branch → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
(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".
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?
any additional filter is a nontrivial amount of work (and IO), thus the current filters are really simple.
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.
(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.
Depends on: 769348
(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)
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. :-(
(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?
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.