23777 - Failure to load frameset at http://members.xoom.com/*

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[John Morrison]

This bug report is split out from an earlier networking bug #22032 at
this URL.

Overview Description:
    Crash in win95 xpcom.dll at http://members.xoom.com/Eturnia/
    (I'm starting this with XPCOM as that's the DLL that the crash
     reports, but XPCOM may just be the victim -- needs a stack trace
     to say for sure).

Steps to Reproduce:
 1) Launch mozilla.
 2) Go to http://members.xoom.com/Eturnia/
 3) chug, chug, chug, Boom!

Actual Results:   crash (after apparent rapid rise in memory used)

Expected Results: page should load normally (ironically, though this
 is now the second bug I have filed for this page, and yet I haven't
 a clue what this site is about -- I'm just reporting 'em for others).

Build Date & Platform Bug Found: 2000011108 on win95

Additional Builds and Platforms Tested On: none (but see from valeski below)

Additional Information:
  I think this bug actually applies to any page at members.xoom.com. I
 went to a couple of other random pages, and crashed the same way.

 Note that the URL reported is a two-frame frameset -- top frame is XOOM
 banner bar, and the lower frame is the users' content. The frameset does
 some js magic with its contents, but I haven't spent anytime decoding it
 yet. (I imagine it's purpose to force "frame encapsulation" of member pages.)

 Comment from valeski on bug #22032 :
   > hmm. a new bug should be filed, but http://members.xoom.com/Eturnia/
   > loads just fine for me on my winnt build.

 One thought: it may not crash on valeski's machine because I have 'bob
 the laptop' [24MB RAM, 72MB max VM]. i.e., it crashes when it can't
 createobject -- no memory). I guess the other way to see this bug
 would be to watch process memory with Task Manager on WinNT.

 (However, I'd be pleased to test this theory on a shiny, new machine,
 as long as one of you buys :-])

Comment 1

[Suresh Duddi (gone)]

This worked on linux too. Could be a low mem issue. Can testing verify this
please.

Comment 2

[Paul MacQuiddy]

I see this happening on win98 and NT4.0 on 1/18 release commercial builds. I
don't think it is restricted to a low-memory machines as I tested on 128Mb
boxes. Seems okay on linux. Sending back to dp (sorry) and setting gerardok as
qa contact for re-assignment as it is a content issue.

Comment 3

[John Morrison]

One thing that I noticed about members.xoom.com/whatever pages was that
they all have this kind of structure (abbreviated):
        <frameset onload='doRewrite();'>
           <frame name='pb'>
           <frame name='thePage'>
        </frameset>
 Now, in 4.x and the js client docs, the onload handler for <frameset> fires
*after* the two child frames have loaded (have fired onload). But in
mozilla it fires without waiting for the child frames to load.

 In the particular case of 'members.xoom.com/whatever', doRewrite()
manipulates the DOM of <frame name='thePage'>. But "thePage" hasn't loaded
at the time that doRewrite() tries to rewrite it's links. This may be the
trigger of the eventual crash. (At the very least, it's a bug in its own
right -- I'll set up a simple test case and update this bug or file a new
one.) But cc: vidur, in case this is already something he knows about.

Comment 4

[Suresh Duddi (gone)]

Vidur, this seems to right up your alley.

Comment 5

[vidur (gone)]

Well...the described bug could well be considered a webshell issue, but I'll
hold onto it. Currently onload handlers are firing from notifications that end
up in the webshell. The notification for the frameset probably happens when the
frameset document itself completes loading. This doesn't match DOM expectations,
which might mean we need to store additional state.

I'm also having a hard time reproducing the problem on my NT machine. Since it's
pretty timing related, that's not a surprise. Any hints on reproducing would be
much appreciated. Either way, there's no reason that this has to be a M13 bug.
I'm moving it out to M14.

Comment 6

[John Morrison]

Yes. This is not M13 especially since ... Hrm. The behaviour of mozilla has
*completely* changed with today's 2000011908 win95. But it is still
crashable (for me). Here are steps to reproduce _as_of_today_

1) Start Mozilla

2) go to http://members.xoom.com/Eturnia

3) the page (for me) will "load" in ~4 seconds, but the canvas is completely
   white and no HTMLFrames are created. (But the status area on the browser
   (window.status) seems to indicate that more than one GET is performed).

4) Hit the reload button. Repeat as necessary. (Sometimes one reload,
   usually two).

5) When it does crash, it crashes immediately (as compared to when I
   originally reported this crash -- then it would sometimes head off,
   leaking MB of memory, until a crash after 30 to 50 seconds -- note: those
   times are on a 133MHz box over dialup).

I received crashes with the win95 error box reporting any of CAPS.DLL,
GKHTML.DLL, JS3250.DLL, and 'module <unknown>'.

[I've put up a simple test-case to demo the HTMLFrame onload behaviour (but
this example does not try to manipulate any DOM, so it's not a crasher. (On
Nav4.x it throws up alerts to show the load order, and in moz it uses dump()
to put messages on the console.]

    http://qsilver.queensu.ca/~buslib/frameload/parent.html

(Ignore the old test crap at !buslib'; the www server was recently changed,
and I have to update the links for the new security rules).

Comment 7

[John Morrison]

... and as of 2000012108, I cannot get this page to crash in any of the ways
noted above. However, this frameset comes up completely blank (e.g., equivalent
to <HTML></HTML>). View Source is also completely blank. 'File -> Save Page 
As...' yields a zero-length file. (Yet, the progress meter on the save, and 
window.status suggest that GET's are being done). 

Comment 8

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 9

[John Morrison]

I note that this URL is no longer a crasher. However, as noted Jan 21, the
frameset is completely blank (2000-02-03-10 win95 opt). I tried a few other
random pages on members.xoom.com (search on 'foo'), and they are also blank,
so, it looks like (seamonkey+members.xoom.com == dead pages). So, given the 
number of pages this affects, that would make this fix a must-have for beta, 
IMO.

Comment 10

[rickg]

This problem looks nasty enough for consideration; marking PDT+.

Comment 11

[Doug Turner (:dougt)]

change component to HTMLFORMS.  I am not sure that this is correct, but pretty 
sure that this is not a xpcom bug

Comment 12

[vidur (gone)]

I cannot reproduce this on either NT or Linux on the 2/10/2000 build? Is this a 
Win95 only issue? Marking WORKSFORME. Please send me mail if you have more 
information.

Comment 13

[John Morrison]

Well it looks like this may be win95 (or win9x) only. Or perhaps, only in an
optimized build vs. a debug build. Using 2000-02-10-14 win95, I get the same
blank canvas (no frames), view source is blank, and "File->Save As" yields a
zero byte file. Let me know what other information I can provide. By the way,
these other, random 'foo' pages are also "blank" (for me). 
  http://members.xoom.com/fooviews
  http://members.xoom.com/foo_icq 

Comment 14

[vidur (gone)]

Rick, I'm giving this to you to reassign. I'm not even sure why I got it in the

first place. My beta1, PDT+ plate is full.

Comment 15

[rickg]

Eric -- you're a stud; please take a look at this one too. Thanks.

Comment 16

[Eric Pollmann]

Reassigning to Kevin per today's meeting.  Kevin, are you familiar with this 
issue?  It sounds like it may be related to gfx or views on Win95 only.

Comment 17

[Eric Pollmann]

Here's a trace of the network traffic I saw during this exchange:

main> Connected to ServerClient4 IP=members.xoom.com; PORT=80
Client4> GET /Eturnia HTTP/1.0
Client4> Host: members.xoom.com
Client4> User-Agent: Mozilla/5.0 (Windows; N; Win95; en-US)
Client4> Accept: */*
Client4> Accept-Language: en
Client4> 
ServerClient4> HTTP/1.1 302 Moved Temporarily
ServerClient4> Date: Wed, 16 Feb 2000 01:11:36 GMT
ServerClient4> Server: Apache/1.2.5
ServerClient4> Location: http://blueviper:8002/members.xoom.com/Eturnia/
ServerClient4> Connection: close
ServerClient4> Content-Type: text/html
ServerClient4> ----- Got HTML Content Type
ServerClient4> ----- End header
ServerClient4> 
ServerClient4> 
ServerClient4> <HTML><HEAD>
ServerClient4> <TITLE>302 Moved Temporarily</TITLE>
ServerClient4> </HEAD><BODY>
ServerClient4> <H1>Moved Temporarily</H1>
ServerClient4> The document has moved <A
href='http://blueviper:8002/members.xoom.com/Eturnia/'>here</A>.<P>
ServerClient4> </BODY></HTML>
main> Child 3 exiting...
main> Got Client5 IP=206.222.241.108; PORT=1755
main> Process 4 (2463) handling request
main> Process 5 (2464) going back for request.
main> Listening for connection Client6....
Client5> ----- Request for members.xoom.com
main> Opening server connection ServerClient5....
main> Connected to ServerClient5 IP=members.xoom.com; PORT=80
Client5> GET /Eturnia/ HTTP/1.0
Client5> Host: members.xoom.com
Client5> User-Agent: Mozilla/5.0 (Windows; N; Win95; en-US)
Client5> Accept: */*
Client5> Accept-Language: en
Client5> Referer: http:///members.xoom.com/Eturnia
Client5> 
ServerClient5>   
ServerClient5> <HTML>
ServerClient5> <HEAD>
ServerClient5> <BASE target="_top">
ServerClient5> <TITLE>
ServerClient5> Eturnia
ServerClient5> </TITLE>
ServerClient5> ----- End header

Comment 18

[Kevin McCluskey (gone)]

I tried in on WIN95 with todays build and the reason the page is blank is 
because it is not loading the document at all. It worked fine for me on WINNT.

Using pollmann's server: blueviper to capture the http header and talking to 
Rick Potts it sounds like the http header is generated by a 0.9 server. 

Although the code parse 0.9 header is cross platform, Rick suggested that I 
reassign to Necko for further investigation. 
 

Comment 19

[Warren Harris]

-> rpotts

Comment 20

[rpotts (gone)]

I just tried the URL using a tip build (2/18/2000) on Win95 and the page loaded
fine...

I'm marking this one works for me...  Please reopen it if anyone is still seeing
the problem.

Comment 21

[John Morrison]

Awfully sorry, but ... using 2000-02-21-08 on win95 B, I cannot load
the URL 'http://members.xoom.com/Eturnia/'. Today (sigh) what happens
is that the canvas/viewport is not repainted at all -- the previously
loaded URL remains on screen (actually the canvas picks up whatever
was last on screen).  History is updated, but the "Eturnia" page is
definitely not loaded (despite status messages that claim success). 

Comment 22

[rpotts (gone)]

OK...  I think I've *finally* tracked this one down...  It looks like the 
problem is caused by a floating point rounding error when determining the HTTP 
server version !

When the server version being passed in is 'HTTP/0.9' - which is a fabricated 
version since 0.9 servers don't send any status back - a rounding error can 
occur.  This causes nsHTTPResponse::SetServerVersion(...) to fail which 
ultimately causes the connection to be torn down because we think that the 
server is sending a bogus status line :-(

I have a fix and I'm waiting for a code review...

Comment 23

[Suresh Duddi (gone)]

Wow! just Wow!

Comment 24

[rpotts (gone)]

I've just checked in the fix...

Comment 25

[John Morrison]

With 2000030516 mozilla.org bits on win95 (the affected platform), this 
frameset now loads. Thanks Rick.

[I do get another DOM error while loading (onload handler fires before child
framesets have loaded) but that is a different issue. I will open a new bug 
for that one].