224447 - Using Proxy Auto Config stops DNS resolution from happening asynchronously - This causes the UI to hang while name resolution occurs

Status: RESOLVED DUPLICATE of bug 188332

(Core :: Networking, defect)

Description

[junk]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

If I go to http://www.citizenwatches.com firebird will hang trying to resolve
the name.  During this period I cannot resolve any other names when I click on
links in different firebird windows which point to hosts that have not been
resolved in the current session.  The easiest way to see this is to open two
firebird windows.  Then in the first, go to http://www.citizenwatches.com.  In
the second pick a url at random that you know should work...i did
http://www.ford.com.

I chose the above sites for this bug because they are reproducable.  However, I
find that this occurs rather often when using firebird.  For example google
search results.

Reproducible: Always

Steps to Reproduce:
1.  Open two firebird windows.
2.  Go to http://www.citizenwatches.com in one window.
3.  Go to another random url you haven't visited before that you know should
work...i.e http://www.ford.com

Actual Results:  
Firebird will be unable to resolve http://www.citizenwatches.com and will hang.
 Likewise any attempt to resolve another host will hang until
www.citizenwatches.com times out.

Expected Results:  
I would expect to be able to browse in other windows normally, even while a dns
query is hung up in one of the windows.

Comment 1

[black-hole]

Very similar problem, using 1.5 and W98, if the browser starts to hang on some
URL (resolving...) often others stop workiong, too. This seems also to appear
when I go offline and online again (and I do that often cause I've got no
flatrate etc.).
If i copmletely restart Mozilla it works fine. Also, other browsers still can
get me the pages from the requestet url while mozilla ist resolving. It seems
that Moz. thinks it is still offline or something, even if I tell him "work
offline" and then uncheck it again. 

Comment 2

[Jason Barnabe (np)]

It gives me "not found" alert right away, so I can't reproduce.

Comment 3

[Tobias Schacht]

I see this bug too with Fb 20031125.

Comment 4

[Hussam Al-Tayeb]

I've seen this in firebird before, but I don't think happens always.

Comment 5

[harm]

this works ok for me with mozilla 1.6b.

from comment #1:
>Very similar problem, using 1.5 and W98, if the browser starts to hang on some
>URL (resolving...) often others stop workiong, too. This seems also to appear
>when I go offline and online again (and I do that often cause I've got no
>flatrate etc.).
>If i copmletely restart Mozilla it works fine. Also, other browsers still can
>get me the pages from the requestet url while mozilla ist resolving. It seems
>that Moz. thinks it is still offline or something, even if I tell him "work
>offline" and then uncheck it again. 
This is solved in 1.6a/b

Comment 6

[mike]

Also experiencing this.  Firebird 0.8+ MacOS X
Resolving Host takes about 5 seconds for any page with a new DNS.  For example,
if i go to www.google.com, it will hang for a few secs at resolving host before
loading, but then anything i do within google will be snappy.  But, say i click
a link from google to another site, it will hang for another few seconds until i
can get into that new site's DNS.

Comment 7

[emmet]

This ought to be renamed to "Complete hang when DNS resolving/lookup"

I see this too, but not always (local site dns cacheing?) -- and experienced
this also when using Mozilla. 

Note: IE does not hang -- that is, its menus etc still function, it can redraw
etc while the lookup occurs.


(Firefox 0.8, Win2K, via a proxy squid/2.5.STABLE3)

Comment 8

[Jason Barnabe (np)]

*** Bug 234282 has been marked as a duplicate of this bug. ***

Comment 9

[Stewart Jeacocke]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040224

As of 23/02/04 I'm still seeing this bug on the SeaMonkey CVS Tree. The UI 
(every windows and tab) is blocked while name resolution is performed. This is a 
real PITA particulary for sites which have many adds etc. For example it can 
take over 30s for http://www.ebay.co.uk to load during which time the UI is 
completely hung.

This bug seems to be due to two things
i) The UI is blocked during host resolution
AND
ii) Host resolution in mozilla is sometimes very slow, even when the dns names 
have already been cached at a local DNS server. For example I used the "host" 
command to resolve all the names required for www.ebay.co.uk and none of them 
took longer than 0.05s to resolve

Comment 10

[Stewart Jeacocke]

This bug is not specific to Firefox. Would it be a good idea to change "Product" 
to something other than FireFox?

I've stuck some cout statements at the beginning and end of nsDNSService::
Resolve() [nsDNSService2.cpp] and can confirm that we are inside this method 
when the UI hangs.

I'm willing to help track down the cause of this bug (as its making me have to 
use Opera ;-) ) but I have no experience with the internals of mozilla so would 
need guidance as to where to start looking.

Comment 11

[Stewart Jeacocke]

It seems that this bug is triggered by something in my preferences. I moved my
.mozilla directory out of the way and let mozilla create a new one. This caused
the bug to disappear (at least on current CVS and mozilla 1.6).

When using my old .mozilla dir (the config the elicits this bug) the method
nsDNSService::Resolve() is being called lots, however when I let mozilla create
.mozilla from scratch nsDNSService::Resolve() is never called and is replaced by
calls to nsDNSService::AsyncResolve()

Comment 12

[Stewart Jeacocke]

The offending preference is enabling Proxy Auto Config (PAC).

When I enable PAC (set to use a valid remote PAC file) the
nsDNSService::Resolve() method is used. When I either manually set the proxy
config or select "direct connection" the nsDNSService::AsyncResolve() method is
called.

SUMMARY
Using Proxy Auto Config stops DNS resolution from happening asynchronously. This
causes the UI to hang while name resolution occurs. 

Comment 13

[Jason Barnabe (np)]

Moving to Browser, good work Stewart.

Comment 14

[Jason Barnabe (np)]

*** Bug 213751 has been marked as a duplicate of this bug. ***

Comment 15

[Stewart Jeacocke]

Not sure if this helps but this is a example bracktrace that I get if I set a 
breakpoint on the nsDNSService::Resolve() method (with proxy auto config 
enabled).

#0  nsDNSService::Resolve(nsACString const&, int, nsIDNSRecord**) 
(this=0x8110a50, hostname=@0x889d658, bypassCache=0, resul$
#1  0x4012a025 in XPTC_InvokeByIndex () from ./libxpcom.so
#2  0x4089e3b7 in XPCWrappedNative::CallMethod(XPCCallContext&, 
XPCWrappedNative::CallMode) (ccx=@0xbfffe650, mode=CALL_METH$
#3  0x408a8913 in XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, 
long*) (cx=0x818cce0, obj=0x87fd680, argc=2, arg$
#4  0x401b2770 in js_Invoke (cx=0x818cce0, argc=2, flags=0) at jsinterp.c:941
#5  0x401c0660 in js_Interpret (cx=0x818cce0, result=0xbfffedcc) at 
jsinterp.c:2962
#6  0x401b27ea in js_Invoke (cx=0x818cce0, argc=3, flags=2) at jsinterp.c:958
#7  0x40896e3b in nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned 
short, nsXPTMethodInfo const*, nsXPTCMiniVariant$
#8  0x4088fd2f in nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo 
const*, nsXPTCMiniVariant*) (this=0x88ef1a0, me$
#9  0x4012a396 in PrepareAndDispatch (methodIndex=4, self=0x88ef1a0, 
args=0xbffff214) at xptcstubs_gcc_x86_unix.cpp:100
#10 0x40ad6c23 in nsStreamListenerTee::OnStopRequest(nsIRequest*, 
nsISupports*, unsigned) (this=0x81e8ba0, request=0x8854778$
#11 0x40b780a6 in nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*, 
unsigned) (this=0x8854778, request=0x88c1898, ctxt$
#12 0x40aae8ca in nsInputStreamPump::OnStateStop() (this=0x88c1898) at 
nsInputStreamPump.cpp:498
#13 0x40aae2e8 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) 
(this=0x88c1898, stream=0x889d4cc) at nsInputS$
#14 0x400d87c7 in nsInputStreamReadyEvent::EventHandler(PLEvent*) 
(plevent=0x8891454) at nsStreamUtils.cpp:118
#15 0x400fc41b in PL_HandleEvent (self=0x8891454) at plevent.c:671
#16 0x400fc2d0 in PL_ProcessPendingEvents (self=0x80bd5a8) at plevent.c:606
#17 0x400ff4ec in nsEventQueueImpl::ProcessPendingEvents() (this=0x80bd570) at 
nsEventQueue.cpp:391
#18 0x416ec720 in event_processor_callback (data=0x80bd570, source=9, 
condition=GDK_INPUT_READ) at nsAppShell.cpp:186
#19 0x416ec0cd in our_gdk_io_invoke (source=0x81ec768, condition=G_IO_IN, 
data=0x81ee1f0) at nsAppShell.cpp:71
#20 0x4042fa56 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
#21 0x4043103d in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#22 0x404314f4 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#23 0x40431724 in g_main_run () from /usr/lib/libglib-1.2.so.0
#24 0x40358c3f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#25 0x416ecb4e in nsAppShell::Run() (this=0x811dca0) at nsAppShell.cpp:317
#26 0x4169c4cc in nsAppShellService::Run() (this=0x811d408) at 
nsAppShellService.cpp:483
#27 0x080570e9 in main1 (argc=1, argv=0xbffff744, nativeApp=0x809e540) at 
nsAppRunner.cpp:1291
#28 0x08057d16 in main (argc=1, argv=0xbffff744) at nsAppRunner.cpp:1678

Comment 16

[Jack Mathews]

ummm, this is not the original bug.

The original bug is about one request holding up others, but not locking up the
UI.  This Proxy one is about the UI locking up, which clearly does not happen.

Comment 17

[Stewart Jeacocke]

> ummm, this is not the original bug.

>The original bug is about one request holding up others, but not locking up the
>UI.  

That may well be true. Im not to sure what the orginial reporter means. However,
what I am describing is exactly what [e-mail] reported (comment #7).

> This Proxy one is about the UI locking up, which clearly does not happen.
Are you saying that when you use "Auto Proxy configuration" your UI does not
hang while name resolution occurs?

Comment 18

[Jack Mathews]

>> This Proxy one is about the UI locking up, which clearly does not happen.
> Are you saying that when you use "Auto Proxy configuration" your UI does not
> hang while name resolution occurs?

No, what I am saying is the original bug talks about stacking up of DNS
resolutions, but the UI not locking up.  "The easiest way to see this is to open
two firebird windows.  Then in the first, go to http://www.citizenwatches.com.
In the second pick a url at random that you know should work...i did
http://www.ford.com."

Can you do THIS in your proxy bug?  Open two windows and type anything in the
second while the first is processing?  Since your proxy bug is a UI lockup, and
the bug description doesn't describe that, then you indeed have a seperate bug
and it should be filed as such, and this bug restored.

Comment 19

[Stewart Jeacocke]

You're right. I only really read comments #6 and #7 before adding my
observations to this bug.

So my reports #9 thru to #15 should go into a new bug. At the same time I would
move comments #6 and #7 into this new bug as I believe they are describing the
bug that I am seeing and not the original one.

I'll go ahead and file this new bug. But someone needs to clean this one up.

Comment 20

[Jason Barnabe (np)]

At this point, it would probably be easier to start a new bug for the original
bug, since most of the information here pertains to the bug mentionned in
comment 6 and comment 7.

Comment 21

[Stewart Jeacocke]

I have filed "Auto Proxy" bug as bug #235853

Comment 22

[Jason Barnabe (np)]

And this is now a dupe.

*** This bug has been marked as a duplicate of 188332 ***