1073846 - Wrong URL loads after autofill of a hostname that matches a search engine, e.g. https://twitter.com/search-home

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Matt Brubeck (:mbrubeck)]

[Tracking Requested - why for this release]:

Steps to reproduce:
1) Use a profile where "https://twitter.com" is one of the most-frecent URLs.
2) Begin typing "twitter" into the Firefox address bar.
3) When the address bar has autofilled "twitter.com", press Enter.

Expected results: Firefox navigates to https://twitter.com/
Actual results: Firefox navigates to https://twitter.com/search-home

Probably related to bug 1071481 and bug 1065303.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

This is intentional, but it obviously doesn't work well for Twitter.

The key here is that it's matching a search engine. We autofill the domain of the search engine, but that's only the user-exposed URL. What we end up navigating to is the engine's search form URL.

Over to Gavin, since he's been overseeing the search stuff.

Comment 2

[Marco Bonardo [:mak]]

yes, we navigate to the searchform of the engine...

Comment 3

[Marco Bonardo [:mak]]

btw, we might first check if we have an autoFill result and only we don't have one try the search engine match.

Comment 4

[Dirkjan Ochtman (:djc)]

Man, this is annoying. Hope we can get it fixed soon.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #3)
> btw, we might first check if we have an autoFill result and only we don't
> have one try the search engine match.

We probably need to do this and revisit the underlying design from bug 958188.

Comment 6

[Matt Brubeck (:mbrubeck)]

For reference, in a default en-US profile, this also breaks the ability to type "ebay.com" or "wikipedia.org" to navigate quickly to the eBay or Wikipedia home pages.

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

Comment 8

[Marco Bonardo [:mak]]

Comment on attachment 8496805 [details] [diff] [review]
Patch v1

Review of attachment 8496805 [details] [diff] [review]:
-----------------------------------------------------------------

sounds good as an interim solution. it won't save us in the case the host has not been typed first, but it's not an unrecoverable situation for the user.

::: toolkit/components/places/tests/unifiedcomplete/test_searchEngine_host.js
@@ +2,5 @@
>   * http://creativecommons.org/publicdomain/zero/1.0/ */
>  
> +Cu.import("resource://testing-common/httpd.js");
> +
> +let addTestEngines = Task.async(function* (items) {

Is Task.async really needed here? why not just a generator function?

@@ +26,5 @@
> +          Services.obs.removeObserver(obs, "browser-search-engine-modified");
> +          engines.push(engine);
> +          resolve();
> +        } catch (ex) {
> +          reject(ex);

there should be no need to try/catch here, if the resolving function throws the promise is rejected automatically with the given exception

Comment 10

[Andrew McCreight [:mccr8]]

If this is annoying you, you can locally work around it by deleting all of the search engines that you are hitting this on from this list, under the "manage search engines" option.

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/integration/fx-team/rev/b327a052e47f

Comment 12

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/fx-team/rev/29854f8b8dd9 since it wasn't entirely clear whether the bc1 bustage was (just) from bug 1070778.

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Bustage was indeed due to the other bug this landed with. Relanded:

https://hg.mozilla.org/integration/fx-team/rev/01a525d9c6c2

Comment 15

[Julian Viereck]

(In reply to Blair McBride [:Unfocused] from comment #1)
> This is intentional, but it obviously doesn't work well for Twitter.
> 
> The key here is that it's matching a search engine. We autofill the domain
> of the search engine, but that's only the user-exposed URL. What we end up
> navigating to is the engine's search form URL.

The main point here is that many sites are not only search engines. E.g. Twitter is also a content provider and therefore I think falling back to assuming the user wants to visit the page to perform a search breaks the experience of the user. In fact, I never thought about using Twitter as a search engine before en-counting this bug.

Google Chrome requires an explicit action from the user to use a URL as a search provider: e.g. 
- I performed a search on dict.cc before
- I enter dict.cc in the URL bar of Google Chrome
- I press <tab> and now Google Chrome is treating the input as a search argument

Maybe what Google Chrome is doing here is better? Treat by default the input as "what the user typed" and direct to the URL but have an easy way to switch to the "Treat this page as a search provider".

Comment 16

[Marco Bonardo [:mak]]

The scope of the feature is to simplify discovery of search engines to new users, but clearly this doesn't play extremely well with experienced users. The outline is in bug 958188. We might want to tweak the behavior still, the problem is not much the fact we autoFill, but the fact some searchForm(s) are not that useful (like the twitter one).
Fwiw this feature can be disabled setting browser.urlbar.autoFill.searchEngines to false.

Comment 17

[Carsten Book [:Tomcat]]

sorry had to back this out for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=49392936&tree=Fx-Team starting with this push on fx-team

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/01a525d9c6c2

Comment 19

[Marco Bonardo [:mak]]

(In reply to Carsten Book [:Tomcat] from comment #17)
> sorry had to back this out for test failures like
> https://tbpl.mozilla.org/php/getParsedLog.php?id=49392936&tree=Fx-Team
> starting with this push on fx-team

doesn't look like the backout has solved the dt1 failure, and indeed I'd be very surprised if there would be a relation at all.
why the backout has not been backed out then?

Comment 20

[Marco Bonardo [:mak]]

relanded again, hoping it won't be backed out for a failure in b2g ;)
https://hg.mozilla.org/integration/fx-team/rev/250cb4595afb

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/250cb4595afb

Comment 22

[Andrei Vaida [:avaida]]

Verified fixed on Nightly 35.0a1 (2014-10-08) using Windows 7 64-bit, Ubuntu 14.04 LTS 32-bit and Mac OS X 10.9.5. 

Note: if (e.g.) https://twitter.com/ is not one of the most frequently visited URLs in the user's browsing history, the user will still be redirected to its search engine match ("https://twitter.com/search-home") and not to the auto-filled URL ("twitter.com"). It was my understanding that this is the expected behavior, if I'm mistaken please let me know.

Comment 23

[Marco Bonardo [:mak]]

it's correct, we are re-evaluating that behavior in a separate bug 958188, but that doesn't matter here.