92675 - Half or less images load on www.businessweek.com / Links don't work

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Benjamin Mucci]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.2+) Gecko/20010727
BuildID:    2001072711

Every time I access http://www.businessweek.com/ half or less of the Web page
images are loaded. Also no link or reload function works. The only thing that
works is the Back function. After clicking Back if I try other sites no prob.
Try to clear cache / relaunch Moz: Nothing works, everytime the same result. In
NS4.7 everything works great. 

Reproducible: Always

Comment 1

[Tuukka Tolvanen (sp3000)]

Works for me on win98 trunk 2001072603

Comment 2

[basic]

works for me win32 2001072603

Comment 3

[Benjamin Mucci]

This morning it hangs (completely or just the images) or completely loads 
sporadically (when it loads completely Moz makes an weird double reload) but in 
NS4.7 it works every time... It's the only site I know who have this weird 
behavior and I reproduce on 2 Mac with same build 2001072711/OS 8.6.

Comment 4

[Brad Tiffany]

I see this reliably on build 2001072508 on MacOS 8.6.  However, if I change the
http version from 1.1 to 1.0, the page will load completely and the links will work.

Comment 5

[Greg K.]

Confirmed under Mac/2001071903. I believe this is a dup of a bug about Mozilla and some 
http 1.1 servers not playing nice, but I can't find the bug at the moment.

Comment 6

[harishd]

Based on the comments handing over to netlib folks.

Comment 7

[Pierre Saslawsky]

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

Comment 8

[Pierre Saslawsky]

Reopening.  My mistake: it's not a dup of bug 91034 (but it could be a dup of bug 
82720).

Comment 9

[Darin Fisher]

still with us as of 8/17/2001 (tested on linux)

Comment 10

[Darin Fisher]

still with us as of 8/17/2001 (tested on linux)

Comment 11

[Darin Fisher]

WORKSFORME: linux 8/21/2001 CVS debug build.

Comment 12

[Benjamin Mucci]

Can reproduce in
Mozilla 0.9.3+ Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010821 08

Comment 13

[Darin Fisher]

Reopening... benjamin: can you set the Platform/OS fields correctly?  Thanks!

Comment 14

[Benjamin Mucci]

Voilà
--> MacOS 8.6

Comment 15

[Tomi Leppikangas]

I have seen quite many pages that doesnt load all images, they
usually work second time you visit, so its hard to get any info.

Allways when this happens, netstat shows that all connections to
proxy are timed out, so no real connections to network exists.

Now i finally managed to get log from this, loading businessweek page.

At end of log you see two lines that comes there after i hit stop
button after 2-3mins page hanged.

1024[8057538]: nsHttpChannel::Cancel [this=8b081e0 status=804b0002]
1024[8057538]: nsHttpChannel::Cancel [this=87c51a8 status=804b0002]

When you search log were those channels get created, they look bit differend
than others:

1024[8057538]: nsHttpHandler::OnModifyRequest [chan=8b081e0]
1024[8057538]: nsHttpChannel::SetRequestHeader [this=8b081e0 header=Cookie
value=(null)]
1024[8057538]: nsHttpChannel::AsyncOpen [this=8b081e0]
1024[8057538]: nsHttpChannel::Connect [this=8b081e0]
1024[8057538]: nsHttpChannel::OpenCacheEntry [this=8b081e0]
1024[8057538]: nsHttpHandler::NewURI           *****
1024[8057538]: nsHttpHandler::NewURI

Usually line with *** is "got cache entry [access=2]", maybe bug is there?

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.cpp#604

I'll attach longish log file (~4mb)

Comment 16

[Tomi Leppikangas]

Attachment: gziped log with NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5

Comment 17

[Darin Fisher]

i think i know what is going on here... attaching a patch.

Comment 18

[Darin Fisher]

Attachment: v1.0 might fix the problem

Comment 19

[Darin Fisher]

tomi: can you give this patch a try and let me know if it solves the problem?

thanks!

Comment 20

[Benjamin Mucci]

Darin: I think that I get a very similar behavior of Mozilla on
http://www.insight.com/web/index.php 

Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010823
2001082304

Comment 21

[Dave Barrowman]

Another topembed testcase: http://www.hgtv.com 

Typically 3-5 images on this page do not load for me in Gecko 08/22/2001builds
from both the trunk and branch. 

Comment 22

[Tomi Leppikangas]

Pages seem to load better with patch, havent had any problems yet. I
tryed all links i found in bug 82720 and all worked fine.

My system is linux, so i guess this is all platform bug.

Comment 23

[Benjamin Mucci]

With 2001082404 MacOS 8.6 it take me 3 reloads to have all the images loaded...

Comment 24

[Darin Fisher]

the patch for bug 83526 includes this patch, and is scheduled to land for
0.9.4... however this smaller patch should probably land on the 0.9.2 branch for
embedding.

Comment 25

[Darin Fisher]

tested the patch on MacOS 9.1, and it seems to do the trick.

Comment 26

[Benjamin Mucci]

Works great today on 2001082805 MacOS 8.6

Comment 27

[Darin Fisher]

this patch (taken from my patch for bug 83526) has r=bbaetz and sr=dougt already.

Comment 28

[Darin Fisher]

i suspect this patch will fix bug 91429 as well.

Comment 29

[Francisco León]

When the links in the page do not work, does someone get a blank "stop" button
in the toolbar? 
If so, bug 97012 (which i can reproduce on linux) is a dup of this.

BTW, i tried businessweek.com and i can see all images, but the browser gets
stuck in "transferring data from..."
linux 8/24

Comment 30

[Darin Fisher]

right... getting stuck in "transferring data" is some document (probably an
image) not loading.

the problem seems to be most reproducible on the mac.  the problem, i think, is
that a failure from the socket transport is not preventing the connection from
being reused.  a failure from the socket transport could mean many things: 1)
document load was canceled (maybe the image load was redirected), 2) bad URL, 3)
bad connection, etc.  so, basically any number of things could trigger this
condition; however, in most cases our IsAlive test succeeds in pruning out bad
connections before they are reused.  the IsAlive test could be giving false
positives on the mac, which the code knows how to handle most of the time.

Comment 31

[Francisco León]

Attachment: Sniff capture zipfile of webpage

Comment 32

[Francisco León]

I used ethereal on linux to sniff that webpage, and output the log to a zip file
(unzipped it's 200kb long)
Most of it can be seen with a text file editor

I hope it can help someone with better knowledge 

Comment 33

[Darin Fisher]

ethereal crashes each time i open that file.  what version of ethereal did you
use to create that file?

Comment 34

[Darin Fisher]

i ran ethereal myself and didn't see any redirects, which i suppose makes sense
since this is not a bug on linux.

Comment 35

[Francisco León]

0.8.19, the latest stable one on the website
Weird... Try to look the file with a text editor
I tried to make that file with no other apps running so all you see is just what
that webpage does , so unless mozilla tried to download mail (i think not) it
should be very accurate.

But why does the page not load completely if this isn't a bug in linux?
Bug 82720 still giving trouble?

Comment 36

[Darin Fisher]

fixed-on-trunk

retargeting 0.9.2 branch

Comment 37

[Marek Z. Jeziorek]

[e-mail], could you verify it on the trunk, so darin could check it
in to 0.9.2? Thanks

Comment 38

[Olivier Cahagne]

Great, thanks for this fix, using build 2001083003 on Win2k, I can finally
reload http://www.espace-particuliers.creditlyonnais.com/ without having less
and less images loading and finally not being able to load it. Build 2001082922
on Linux also now works perfectly.
This URL was really a nice testcase because reloading it would inevitably lock
the site with Mozilla whereas browsing other sites was still possible.

Comment 39

[Benjamin Mucci]

Mozilla 0.9.3+
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010830 -05

have the "hard version" (need 3 reloads) of the bug on http://
www.businessweek.com/... MacOS 8.6

But http://www.espace-particuliers.creditlyonnais.com/ works great.

Comment 40

[Francisco León]

linux 2001083006 loaded businessweek _totally_ the first time i tried.
Perhaps luck, but now this bug wfm

Comment 41

[bsharma]

Verified on 2001-08-30-Trunk build on WinNT.

Following sites load fine:
http://www.businessweek.com/
http://www.insight.com/web/index.php
http://www.hgtv.com
http://www.espace-particuliers.creditlyonnais.com/

Comment 42

[Francisco León]

Verified on linux too.
Can the mac user verify this too?

Comment 43

[Darin Fisher]

please don't close this bug WORKSFORME... it is not yet fixed on the 0.9.2 branch.

Comment 44

[Benjamin Mucci]

WFM on MacOS 8.6 2001083008. But on one computer the bug was reproducible even
with this build. The workaround was to trash (any idea where can be the
relation!? ) the "Mozilla Registry" in the Preferences Folder.

Comment 45

[Olivier Cahagne]

Benjamin: yes, perhaps the Cache and a different behavious from one build to
another.

Comment 46

[Marek Z. Jeziorek]

could we check this into 0.9.2 branch?

Comment 47

[Darin Fisher]

landed my patch on the 0.9.2 branch.