219512 - IPV6: web page loads hang for several minutes before finishing

Status: VERIFIED DUPLICATE of bug 68796

(Core :: Networking, defect)

Description

[Jim Brown]

User-Agent:       Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.5b) Gecko/20030917
Build Identifier: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.5b) Gecko/20030917

Starting with 2003-09-13 (my earlier trunk build was 2003-09-10) the browser
stalls for several minutes when loading web pages (especially if they have
embedded ads with ad.doubleclick.net).  The chasing arrows (for this tab) are
going and the icon is pulsing.  This also causes loads in other tabs to hang
until the stalled tab either completes or is halted (stop button).
It makes the web browser almost unuseable (at times).

I consistently see the problem with web pages at http://www.washingtonpost.com
including http://www.washingtonpost.com/wp-dyn/nation/,
http://www.washingtonpost.com/wp-dyn/world/ and
http://www.washingtonpost.com/wp-dyn/metro.
Sometimes the articles load ok and sometimes they hang trying to load the ad.

I have tried 'accept images from originating server only' and still see the same
problem.

I wonder if bug 205726 could be the problem.

Platform: Tru64 unix v5.1b.


Reproducible: Sometimes

Steps to Reproduce:
1. jump around on the washingtonpost.com web site using a recent trunk build..
2. generally it is the summary pages that have the problem.

Comment 1

[Jim Brown]

Each hang is about 100 seconds.
Sometimes I see more than one hang per page visited.

Comment 2

[Jim Brown]

The fix for bug 219376 did not change my symptoms.
I still get 90-100 second hangs on ads (doubleclick.net addresses).
There may be some improvement (few pages which hang) but overall the problem
remains.

Comment 3

[Jim Brown]

What ever is going on causes other page (re)loads to hang until the ad site
responds/does whatever it needs to do.
In most cases these ads appear to be inline in the page.
Is there any way I can get mozilla to not load them?
('load images only from this site' doesn't make any difference)

Is there any logging I can enable which might show where the problem lies?
Where should I start and what should I look for?

Comment 4

[hub-san]

I confirm this bug on mozilla-trunk(BuildID: 2003100905, 2003101405).

http://www.washingtonpost.com/wp-srv/contents/

I have same problem at another web pages.  This problem occurred in late
September.  I'm using mozilla-trunk on MacOSX10.2.8.  Safari and MacIE works
fine.  Could you see the list of some sites?

Always:
http://www.yomiuri.co.jp/
http://www.n-tv.de/

Sometimes:
http://www.mainichi.co.jp/

These pages have one or more advertising banner displaying by Javascript.  I
think that mozilla loads these pages more slowly because mozilla takes time to
resolve host(e.g. ad.jp.doubleclick.net, ad.doubleclick.net).  Jim, could you
try turning off Javascript?

I think that this setting is workaround on some cases.  However, this problem is
not in Javascript.  It is problem of "resolving host".

Reference:
http://www.mozilla.gr.jp/tools/cbbs/cbbs.cgi?mode=all&namber=6693&type=0&space=0&no=0
http://forums.mozillazine.org/viewtopic.php?t=27344

Comment 5

[Jim Brown]

I disabled Javascript for Navigator and page loads are much better.
The ads still take a long time (100+ seconds) to load/fill-in but the rest of
the page shows up almost immediately.

I agree that "resolving ..." appears to real problem but I am happy to have a
useable workaround until the root issue is fixed.

I believe this problem started in the 030910--030913 time range.
I do not have hangs with a trunk build pulled 030910 but I do have these hangs
on a trunk build pulled 030913.

This is at least a 'unix' issue (DEC OSF1 and Mac OS X).

Comment 6

[Jim Brown]

The article pages load different with JavaScript turned off (e.g.
http://www.washingtonpost.com/wp-dyn/articles/A21507-2003Oct13.html).
They are formated much wider than normal (almost two pages wide).

Comment 7

[Jo Hermans]

Hub-san, Jim Braun, I think this is a dupe of bug 68796. All the examples used
servers from *.doubleclick.net, which are broken. The bug roared its head when
IPv6 lookups were switched on in September, because we switched from
gethostbyname() to getaddrinfo(), which looks for AAAA records first, and
regular A records later. Doubleclick returns an illegal response for the first
query.

Workaround is to use a proxy-server (for me at least).

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

Comment 8

[David Haas (gone, not reading mail)]

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

Comment 9

[benc]

V dupe.