Closed Bug 972452 Opened 6 years ago Closed 5 years ago

One-word URLbar searches are incredibly slow.

Categories

(Firefox :: Search, defect, major)

29 Branch
x86_64
Windows 7
defect
Not set
major
Points:
13

Tracking

()

VERIFIED FIXED
Firefox 33

People

(Reporter: aeidein, Assigned: Gijs)

References

Details

(Keywords: perf)

Attachments

(1 file)

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.
er, maybe not keyword.url seeing as it's been removed (who knows why), but whatever the default search is.
I can reproduce this issue with the latest Nightly on Win 7 64-bit.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Untriaged → Search
Ever confirmed: true
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.
Severity: enhancement → major
Flags: firefox-backlog?
Keywords: perf
Duplicate of this bug: 985337
This should be fixed with current backlog bug 982428.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 982428
Flags: firefox-backlog? → firefox-backlog-
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?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Flags: firefox-backlog- → firefox-backlog?
(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.
Flags: firefox-backlog? → firefox-backlog+
Whiteboard: p=0
Duplicate of this bug: 1003090
Duplicate of this bug: 1004290
Duplicate of this bug: 1004409
Duplicate of this bug: 1017072
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.
This is a dupe of bug 693808, I'm pretty sure.
I think it'll be fixed by that bug, but what was reported is a different bug (nothing happens, rather than being slow)
Depends on: 693808
Points: --- → 13
Whiteboard: p=0
bug 693808 did indeed fix this! Woo!
Status: REOPENED → RESOLVED
Closed: 6 years ago5 years ago
Resolution: --- → FIXED
Flags: firefox-backlog+
Assignee: nobody → gijskruitbosch+bugs
Target Milestone: --- → Firefox 33
QA Whiteboard: [good first verify]
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]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.