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

VERIFIED FIXED in Firefox 35

Status

()

Firefox
Location Bar
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: mbrubeck, Assigned: Unfocused)

Tracking

(Blocks: 1 bug, {regression, reproducible})

35 Branch
Firefox 35
regression, reproducible
Points:
3
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +
qe-verify +

Firefox Tracking Flags

(firefox35+ verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
[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.
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.
Flags: needinfo?(gavin.sharp)
yes, we navigate to the searchform of the engine...
btw, we might first check if we have an autoFill result and only we don't have one try the search engine match.
Man, this is annoying. Hope we can get it fixed soon.
(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.
tracking-firefox35: ? → +
Flags: needinfo?(gavin.sharp)
Component: Autocomplete → Location Bar
Product: Toolkit → Firefox
(Reporter)

Comment 6

3 years ago
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.

Updated

3 years ago
Blocks: 1071461
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Points: --- → 3
Created attachment 8496805 [details] [diff] [review]
Patch v1
Attachment #8496805 - Flags: review?(mak77)
Flags: qe-verify+
Flags: firefox-backlog+
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
Attachment #8496805 - Flags: review?(mak77) → review+
Duplicate of this bug: 1074456

Comment 10

3 years ago
workaround
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.
https://hg.mozilla.org/integration/fx-team/rev/b327a052e47f

Comment 12

3 years ago
backout
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.

Updated

3 years ago
Blocks: 995091

Updated

3 years ago
Iteration: --- → 35.3

Updated

3 years ago
QA Contact: alexandra.lucinet
QA Contact: alexandra.lucinet → andrei.vaida
Bustage was indeed due to the other bug this landed with. Relanded:

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

Updated

3 years ago
Duplicate of this bug: 1076749

Comment 15

3 years ago
(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".
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.
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
https://hg.mozilla.org/mozilla-central/rev/01a525d9c6c2
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox35: affected → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
(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?
Status: RESOLVED → REOPENED
Flags: needinfo?(cbook)
Resolution: FIXED → ---
relanded again, hoping it won't be backed out for a failure in b2g ;)
https://hg.mozilla.org/integration/fx-team/rev/250cb4595afb
Flags: needinfo?(cbook)
https://hg.mozilla.org/mozilla-central/rev/250cb4595afb
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
status-firefox35: fixed → verified
it's correct, we are re-evaluating that behavior in a separate bug 958188, but that doesn't matter here.
You need to log in before you can comment on or make changes to this bug.