972452 - One-word URLbar searches are incredibly slow.

Status: VERIFIED FIXED

(Firefox :: Search, defect)

Description

[merfius]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140205040203

Steps to reproduce:

Ctrl+L, type "hello", Enter.


Actual results:

Takes 4-5 seconds to perform the keyword.URL search.
"hello^" is significantly faster, as is any multi-word search ("hello world").


Expected results:

There should be a pref to bypass DNS lookup (or whatever's causing the slowdown) and immediately use the keyword.URL entry for any entry not matching a keyword.

Comment 1

[merfius]

er, maybe not keyword.url seeing as it's been removed (who knows why), but whatever the default search is.

Comment 2

[Manuela Muntean [Away]]

I can reproduce this issue with the latest Nightly on Win 7 64-bit.

Comment 3

[Mike Connor [:mconnor]]

Nominating for Firefox backlog.  This is a longstanding pain point for single-word entries in the location bar.  Users switching from other browsers will not get expected results.  IE10 does a straight search, Chrome searches, but asks if I meant http://foo/ if (and only if) foo is a real host.

bug 680869 addresses some of the underlying slowness (NBNS!), which we should look into as a part of addressing this performance issue.  On most networks this is a painfully slow request because it waits for a timeout.  However, we know DNS is slow in general, so this still won't feel fast if we continue to serialize.

For the best possible experience, I'd propose that we change behaviour to match Chrome:

* Assume that a single word is a search, not an attempt to visit a host.
* In parallel to serving the search request, kick off background name resolution to see if there's a host that would have matched.
* If there's a domain that would load today, we pop a notification asking the user if they meant to go to that domain.
* If they answer yes, remember that choice for that host (nsIPermissionManager would be an easy/fast lookup) for next time and navigate instead of search.

Comment 4

[Mike Connor [:mconnor]]

Attachment: how Chrome handles this search

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

This should be fixed with current backlog bug 982428.

Comment 7

[Jennifer Morrow [:Boriss] (UX)]

Not a dup.  Mconnor and I tried a bunch of builds to try and reproduce.  Seems not to be an issue on Nightlies or on OSX.  Mconnor thinks this is because of nbns.  Can anyone reproduce this on nightlies?

Comment 8

[u428464]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #7)
> Not a dup.  Mconnor and I tried a bunch of builds to try and reproduce. 
> Seems not to be an issue on Nightlies or on OSX.  Mconnor thinks this is
> because of nbns.  Can anyone reproduce this on nightlies?

Yes I can clearly reproduce on Nightly on Windows 7. It has always been slow for one word search on this platform. Mac OSX is fine though.

Comment 13

[pionchon.luc]

I would like to add that the behavior is pretty random. Sometimes one-word entry searches immediately. And right now it seems that even multiple-words entry takes time before launching the search.

Overall this is pretty bad UX.

This adds to the feeling of instability and unreliability. Pretty sad.

Comment 14

[:Gijs (out for now; he/him)]

This is a dupe of bug 693808, I'm pretty sure.

Comment 15

[Mike Connor [:mconnor]]

I think it'll be fixed by that bug, but what was reported is a different bug (nothing happens, rather than being slow)

Comment 16

[Mike Connor [:mconnor]]

bug 693808 did indeed fix this! Woo!

Comment 17

[vasilicamihasca]

I was able to reproduce this bug on Nightly 30.0a1 (2014-02-13), using Windows 7 x64.

Verified fixed on Windows 7 x64 using Firefox 33.0b9 (2014-10-08)

This fix can be marked as verified.

[bugday-20141008]