Firefox url bar search slow, because of NBNS queries




8 years ago
3 years ago


(Reporter: dfandrew, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: dupeme)


(3 attachments)



8 years ago
Created attachment 554821 [details]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

I'm a bit puzzled, why Firefox is so uber slow with DNS queries. Whenever I type something into the url bar to launch a google search, Chrome finishes under a second, while Firefox twiddling for 3-4 seconds. What the hell I asked and launched Wireshark to debug the problem.

Actual results:

Wireshark showed that when I press enter, it first does 4x LLMNR queries, then 2 or 3 NBNS queries, and finally it makes a GET request for the search term, in this case: "mikkmakk". The problem is around the NBNS queries, which slows down the whole process a LOT. It takes 2 and a half seconds to make the actual google query!

Chrome does 2 LLMNR queries, NO NBNS queries at all and voilá, it finishes under 0.07 seconds. Thats an almost instant result. 

Both browsers were reopened, purged, whatever. So the question is, how can we disable those NBNS queries, to make Firefox actually competitive vs. Chrome.

Expected results:

Give results in an instant, ergo leave out NBNS queries.

Comment 1

8 years ago
Created attachment 554822 [details]
Chrome search query in wireshark

Comment 2

8 years ago
Firefox doesn't directly query Netbios, that is done by the TCP/IP stack. If a hostname does not contain a dot, by default a Netbios query will be done first. It's slow in your case, because you probably doesn't have a Windows Domain Controller (your home network ?). To disable Netbios lookups : see <>

I'm not sure how Chrome avoids the lookup. Maybe they're always using the full hostname (with domain added) ?

Comment 3

8 years ago
The main problem is. Chrome does it right, Opera does it right, Firefox doesn't do it right. I've included the opera wireshark output. It queries the DNS, but immediately after that makes the GET query, and at the very end, the sluggish NBNS queries get executed/returned. So this looks like a deeper problem, than what you delineated. Chrome and Opera do the queries in parallel, while Firefox waits for the NBNS answer (at least it looks like it is waiting for it). So make it smarter, because at this very moment, Firefox does not have the competitive edge it used to have and the only thing keeps me from dumping Firefox is Firebug.

Comment 4

8 years ago
Created attachment 554855 [details]
Opera wireshark output
Dupe of Bug 402411 (maybe others)?
Whiteboard: dupeme

Comment 6

8 years ago
I'm a programmer myself, so if you tell me what to do, I can do debug, whatever.

Comment 7

7 years ago
I've just tried (new installation, clean profile) a search using the URL bar and it is very slow.

Is the status of this bug still Unconfirmed?

Comment 8

6 years ago
Hi, is this still being looked into?

Comment 9

5 years ago
Using I can see that if you search for a single word e.g. "test" then FX tries to visit http://test/ which takes 4.5sec and returns with error message NS_ERROR_UNKNOWN_HOST.

It is only then that it goes on to the normal search but by then you've lost 4.5 seconds.

Note that this does not happen if you search for two words e.g. "test test".

Can someone please confirm?

Comment 10

5 years ago
Could this be linked to the network.dns.ignoreHostonly pref?

Also, is this a duplicate of

Comment 11

5 years ago
I'm using 30.0 and this bug is still present. Any one-word search term takes around 3-5 seconds longer than either using two or more words OR searching any amount of words using the dedicated Search UI component.
Component: General → Networking
Product: Firefox → Core
Version: 6 Branch → unspecified

Comment 12

5 years ago
I see this bug has been marked as Resolved:

but I can confirm that on Windows and ver 33 this is still an issue as described here:

Comment 14

4 years ago
Also works for me.
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.