Closed Bug 92675 Opened 21 years ago Closed 20 years ago

Half or less images load on / Links don't work


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

Mac System 8.6





(Reporter: benjamin, Assigned: darin.moz)




(Keywords: topembed, Whiteboard: fixed-on-trunk)


(3 files)

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 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
Works for me on win98 trunk 2001072603
works for me win32 2001072603
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.
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.
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.
Ever confirmed: true
Based on the comments handing over to netlib folks.
Assignee: harishd → darin
Component: Parser → Networking

*** This bug has been marked as a duplicate of 91034 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
Reopening.  My mistake: it's not a dup of bug 91034 (but it could be a dup of bug 
Resolution: DUPLICATE → ---
still with us as of 8/17/2001 (tested on linux)
OS: Mac System 8.6 → All
Hardware: Macintosh → All
still with us as of 8/17/2001 (tested on linux)
Keywords: topembed
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4
WORKSFORME: linux 8/21/2001 CVS debug build.
Closed: 21 years ago20 years ago
Resolution: --- → WORKSFORME
Can reproduce in
Mozilla 0.9.3+ Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010821 08
Reopening... benjamin: can you set the Platform/OS fields correctly?  Thanks!
Resolution: WORKSFORME → ---
--> MacOS 8.6
OS: All → Mac System 8.6
Hardware: All → Macintosh
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
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?

I'll attach longish log file (~4mb)
i think i know what is going on here... attaching a patch.
tomi: can you give this patch a try and let me know if it solves the problem?

Darin: I think that I get a very similar behavior of Mozilla on 

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

Typically 3-5 images on this page do not load for me in Gecko 08/22/2001builds
from both the trunk and branch. 
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.
With 2001082404 MacOS 8.6 it take me 3 reloads to have all the images loaded...
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
tested the patch on MacOS 9.1, and it seems to do the trick.
Works great today on 2001082805 MacOS 8.6
this patch (taken from my patch for bug 83526) has r=bbaetz and sr=dougt already.
Whiteboard: r=bbaetz, sr=dougt, a=?
i suspect this patch will fix bug 91429 as well.
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 and i can see all images, but the browser gets
stuck in "transferring data from..."
linux 8/24
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.
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 
ethereal crashes each time i open that file.  what version of ethereal did you
use to create that file?
i ran ethereal myself and didn't see any redirects, which i suppose makes sense
since this is not a bug on linux.
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?
Whiteboard: r=bbaetz, sr=dougt, a=? → r=bbaetz, sr=dougt, a=asa

retargeting 0.9.2 branch
Whiteboard: r=bbaetz, sr=dougt, a=asa → fixed-on-trunk
Target Milestone: mozilla0.9.4 → mozilla0.9.2, could you verify it on the trunk, so darin could check it
in to 0.9.2? Thanks
Great, thanks for this fix, using build 2001083003 on Win2k, I can finally
reload 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.
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:// MacOS 8.6

But works great.
linux 2001083006 loaded businessweek _totally_ the first time i tried.
Perhaps luck, but now this bug wfm
Verified on 2001-08-30-Trunk build on WinNT.

Following sites load fine:
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Verified on linux too.
Can the mac user verify this too?
please don't close this bug WORKSFORME... it is not yet fixed on the 0.9.2 branch.
Resolution: WORKSFORME → ---
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.
Attachment #46963 - Flags: superreview+
Attachment #46963 - Flags: review+
Benjamin: yes, perhaps the Cache and a different behavious from one build to
could we check this into 0.9.2 branch?
landed my patch on the 0.9.2 branch.
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Component: Networking → Networking: HTTP
QA Contact: bsharma → tever
You need to log in before you can comment on or make changes to this bug.