89565 - The browser doesn't reload the bottom chat screen.

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P2)

Description

[Jim Shockey]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

Hi,

If you go into the chat rooms at www.knightsrealm.net or dragonslair.net  or any
chatserver style chat room, the browser doesn't reload the bottom frame to read
the post.

When hitting submit the top frame loads extremly fast but the bottom never does.

Reproducible: Always
Steps to Reproduce:
1. just try posting a message at www.knightsrealm.net
2.
3.

Actual Results:  no message ever shows up.

Comment 1

[Jim Shockey]

I was wondering if anyone has taken a look at this problem.  The browser is 
working great except for the mention bug.  In an HTML type chat room, 
"http://www.dragonslair.net or http://www.knightsrealm.net"  The top frame 
relods very quickly but the bottom frame never reloads when a message is posted.

I'm currently using netscape 4.73 which works like a champ, but I would like to 
use netscape 6 or mozilla because of the email functions.  

I know you folks ae very busy and will get around to looking into this bug.

Thanks

Comment 2

[Sivakiran Tummala]

does reload the frame ...i do not see the problem

Comment 3

[Jim Shockey]

interesting I don't show anyone being in either of those chat rooms testing the 
browser.  the browser does not reload the lower screen when a message is posted.

Comment 4

[Sivakiran Tummala]

use shift reload --- not the reload button on the page....by doing so i did see
the msg i typed in

Comment 5

[Jim Shockey]

I can make the bottom frame reload, but the problem here is it should reload 
itself, the same time the top frame reloads.  The the chat room with netscape 
4.7 or internet explore 5.0.  You will see how the rooms operate.

The bottom frame does not reload.

Comment 6

[Jim Shockey]

Still wondering about this bug, will it be fixed in the furture?  I have been 
asking this to be fixed for over a year.  It would be nice if someone just 
tried.

Comment 7

[Jim Shockey]

The bottom frame doesn't load along with the top frame in the chat rooms at 
www.knightsrealm.net and dragonslair.net.

Comment 8

[Fabian Guisset]

This sounds like a networking issue, because the page never stops loading. When
I try to View either page source of the frame source, I see the source of the
"404-Not found" apache page. Not sure how I could debug this. Marking NEW at any
rate.
Hitting reload does show my comment.

Comment 9

[Amarendra Hanumanula]

 changing the QA contact

Comment 10

[Vladimir Ermakov]

Changing to a more appropriate component: Networking.
The page in the lower frame doesnt finish loading..

Comment 11

[Johnny Stenback (:jst)]

Jim, would you by any chance be able to minimize the site to something smaller
that would be easier to debug? I don't have the time to dig into what this site
is doing...

Comment 12

[Johnny Stenback (:jst)]

mozilla0.9.9

Comment 13

[Johnny Stenback (:jst)]

Pushing to mozilla1.0

Comment 14

[Jim Shockey]

Here's an interesting point, the brower works fine with Caldera Open Linux 
version 2.4. Still no do on mac or PC.

Comment 15

[David Bradley]

I tried it on my Red Hat 6.0 box and it doesn't work. I'm looking into the form
submit logic and post processing so far haven't seen anything unusual.

Comment 16

[David Bradley]

Some other things I have discovered.

If I leave Internet Explorer for a while and then try and submit a message, it
doesn't display as well. Pressing the forms reload button corrects this and it
behaves as it should

When I first enter the chat room with mozilla I get messages in real time from
another browser. However after I submit a message I no longer get messages from
another browser. Pressing the form's reload button corrects this problem as well.

It seems like the IE timeout problem is very similar at least in behavior to
what is happening in Mozilla, it may just be coincidents. But I thought I'd
point it out in case it sparks an idea from someone else.

Comment 17

[Jim Shockey]

That chat room has a time out of 10 or 15 minutes so the connection will
terminate if the chatter is idle for that time.  I think this is what your
seeing with the IE browser, netscape 4.XX and Opera will do the same.

Comment 18

[David Bradley]

Another problem I've noticed, this doesn't always happen, but I get rendering
problems. The top frame's background is all black instead of the image
specified. The bottom frame is all black as well. When messages come in, they
show up in the top frame instead of the bottom frame. I'm not sure if this is
related, or a completely different problem.

Jim: Was wondering if you could post the source for the two frames. I can't get
Mozilla to view/save the source for either of the frames.

Comment 19

[Jim Shockey]

Top frame source



<html>
<head>
<title>The Dungeon :</title>
</head>
<script LANGUAGE="JavaScript">
<!--
    function saysFocus( )
    {
        if ( document.inputForm.SAYS != null )
        {
            document.inputForm.SAYS.focus();
        } else if ( document.inputForm.SAYS0 != null )
        {
            document.inputForm.SAYS0.focus();
        } else if ( document.inputForm.MODSAYS != null )
        {
            document.inputForm.MODSAYS.focus();
        }  // end if
    }  // end saysFocus
  // -->
</SCRIPT>
<body BACKGROUND="http://216.206.136.35/images/dungeon.jpg" BGCOLOR="black"
TEXT="red"><center><b>The Dungeon : - 3 user's</center></b><body>
<pre>
<form METHOD="POST" ACTION="/BANNER" NAME="inputForm"><input NAME="USER"
TYPE="HIDDEN" VALUE="&LT;B&GT;&LT;I&GT;Jim&LT;/I&GT;&LT;/B&GT;"><input
NAME="VERBOSE" TYPE="HIDDEN" VALUE="0"><input NAME="HISTORY" TYPE="HIDDEN"
VALUE="10"><input NAME="LOGIN" TYPE="HIDDEN" VALUE=""><input NAME="USERPASS"
TYPE="HIDDEN" VALUE=""><input NAME="PASSWORD" TYPE="HIDDEN" VALUE=""><input
NAME="MODPWD" TYPE="HIDDEN" VALUE="q3zYq2uQ"><b>Jim</b> <select
NAME="ACTION"><option SELECTED VALUE="says to">says to
<option VALUE="welcome">welcome
<option VALUE="shakes hands">shakes hands
<option VALUE="Says Goodbye to!">Says Goodbye to!
<option VALUE="goodbye">goodbye
<option VALUE="shouts to">shouts to
<option VALUE="PRIVATELY whispers to">PRIVATELY whispers to
<option VALUE="kisses">kisses
<option VALUE="Smacks">Smacks
<option VALUE="hugs">hugs
<option VALUE="Whoops">Whoops
<option VALUE="Taps on shoulder">Taps on shoulder
<option VALUE="Genie">Genie
<option VALUE="french kiss">french kiss
<option VALUE="candle">candle
<option VALUE="fireplace">fireplace
<option VALUE="High 5's">High 5's
<option VALUE="sits">sits
<option VALUE="scowls at">scowls at
<option VALUE="giggles at">giggles at
<option VALUE="smiles invitingly at">smiles invitingly at
<option VALUE="winks suggestively at">winks suggestively at
<option VALUE="caresses">caresses
<option VALUE="pounces on">pounces on
<option VALUE="hands a rose">hands a rose
<option VALUE="shoves">shoves
<option VALUE="gropes">gropes
<option VALUE="nudges">nudges
<option VALUE="ask to dance">ask to dance
<option VALUE="dances with">dances with
<option VALUE="carries to bed">carries to bed
<option VALUE="waterhose">waterhose
<option VALUE="laughs">laughs
<option VALUE="nods to">nods to
<option VALUE="inquires to">inquires to
<option VALUE="glares at">glares at
<option VALUE="smirks at">smirks at
<option VALUE="punches">punches
<option VALUE="whoops upside the head">whoops upside the head
<option VALUE="knocks out">knocks out
<option VALUE="swiftly kicks">swiftly kicks
<option VALUE="kadoogan">kadoogan
<option VALUE="get espresso">get espresso
<option VALUE="proposes a toast to">proposes a toast to
<option VALUE="orders drinks">orders drinks
<option VALUE="drinks with floaties">drinks with floaties
<option VALUE="throws up on">throws up on
<option VALUE="spills a drink on">spills a drink on
<option VALUE="pours a drink on">pours a drink on
<option VALUE="slaps">slaps
<option VALUE="kicks">kicks
<option VALUE="unlease a dragon">unlease a dragon
<option VALUE="inquires innocently of">inquires innocently of
<option VALUE="agrees with">agrees with
<option VALUE="ignores">ignores
</select> <select NAME="WHOTO" SIZE=1><option SELECTED VALUE="Everyone">Everyone
<option VALUE="IEMan">IEMan
<option VALUE="Jim">Jim
<option VALUE="mozman">mozman
</select> <input NAME="MODCMD" VALUE="BOOT" TYPE="SUBMIT"> <input
NAME="BOOTTIME" SIZE=4 TYPE="TEXT" VALUE="30"> minutes<br>
Message: <input NAME="SAYS" SIZE=45> <input NAME="SUBMIT" VALUE="* Submit *"
TYPE="SUBMIT">
</form><form METHOD="POST" ACTION="/" TARGET="_top"><input NAME="USER"
TYPE="HIDDEN" VALUE="&LT;B&GT;&LT;I&GT;Jim&LT;/I&GT;&LT;/B&GT;"><input
NAME="VERBOSE" TYPE="HIDDEN" VALUE="0"><input NAME="HISTORY" TYPE="HIDDEN"
VALUE="10"><input NAME="LOGIN" TYPE="HIDDEN" VALUE=""><input NAME="USERPASS"
TYPE="HIDDEN" VALUE=""><input NAME="PASSWORD" TYPE="HIDDEN" VALUE=""><input
NAME="MODPWD" TYPE="HIDDEN" VALUE="q3zYq2uQ"><input NAME="SUBMIT" TYPE="SUBMIT"
VALUE="Goto"> <select NAME="LEAVE">
<option VALUE="Camelot :">Camelot :
<option VALUE="Squires Chamber :">Squires Chamber :
<option VALUE="Hot Spring">Hot Spring
<option VALUE="Knights Inn:">Knights Inn:
<option VALUE="Leave The Chat:">Leave The Chat:
</select> <input NAME="RELOAD" VALUE="Reload" TYPE="SUBMIT"></form>
<script LANGUAGE="JavaScript1.1">
<!--
    var scrolling = false;
    function toggleScrolling( )
    {
        if ( scrolling == true )
        {
            scrolling = false;
            parent.BODY.clearTimeout();
            parent.BODY.autoScrollOn = 0;
            parent.BODY.onblur = parent.BODY.scrollOffFunction;
        } else {
            scrolling = true;
            parent.BODY.autoScrollOn = 1;
            parent.BODY.onblur = parent.BODY.scrollOnFunction;
            parent.BODY.scroll(0, 65000);
            parent.BODY.setTimeout('scrollWindow()', 200);
        }  // end if
    }  // end toggleScrolling
    if ( parent.BODY != null  && parent.BODY.autoScrollOn != null )
    {
        document.write('<FORM NAME=newForm>');
        document.write('<INPUT NAME=AUTOSCROLL TYPE=CHECKBOX
onclick="toggleScrolling()"');
        if ( parent.BODY.autoScrollOn == 1 )
        {
            document.write(' CHECKED');
        }  // end if
        document.write('> Enable Auto Scrolling');
        document.writeln('</FORM>');
        scrolling = ( parent.BODY.autoScrollOn == 1 );
    }  // end if
  //  -->
</SCRIPT></pre></body></html>


lower frame sorce

<html>
<head>
<title>The Dungeon :</title>
</head>
<body BACKGROUND="http://www.knightsrealm.net/images/dungeon1.jpg"
BGCOLOR="black" TEXT="black">(Tue May  7 10:18:24 2002) IEMan : Test3<p>
(Tue May  7 10:18:27 2002) IEMan : Test4<p>
(Tue May  7 10:18:34 2002) mozman : <i>With a flash of light and distant rolling
of thunder.... fades from sight......</i><p>
(Tue May  7 10:18:45 2002) IEMan : <i>With a flash of light and distant rolling
of thunder.... fades from sight......</i><p>
(Tue May  7 10:20:09 2002) IEMan <i>says to<b> mozman</b></i>: Test<p>
(Tue May  7 10:20:14 2002) IEMan : TEst2<p>
(Tue May  7 10:20:29 2002) IEMan <i>says to<b> IEMan</b></i>: Test3<p>
(Tue May  7 10:25:58 2002) IEMan : <i>With the Crack of distant  Thunder, Flash
of Lightening You've entered the Realm of  the DungeonMaster...</i><p>
(Tue May  7 10:26:03 2002) mozman : <i>With the Crack of distant  Thunder, Flash
of Lightening You've entered the Realm of  the DungeonMaster...</i><p>
(Tue May  7 10:27:33 2002) mozman : This is a test<

Comment 20

[David Bradley]

Attachment: Network log of session

I'm attaching a log of the network session. This consists of bringing up the
initial page door.html, entering the chat page, and then sending a message and
then closing the browser.

I put in an NS_WARNING message to mark the form submits to help break things
out a bit better and manually added horizontal bar === to make it easier to
find.

What it looks like is happening is that the when the *Submit* button is
pressed, a stop request is generated for the http connection (3703f78) this
causes it to be closed and stop receiving the any information. I think this is
why Mozilla says it's never done, it's really never done because it's always
waiting for more information to come in.

So I think the question is, should Mozilla be closing this connection when the
submit button is pressed. I assume this was done so that if images or other
content was still coming down, those transactions would be terminated and not
waste bandwidth. So I don't know if there is some distinguishing attribute to
the connection used for the bottom frame that we should/could be keying off of.

Comment 21

[David Bradley]

It is definitely a problem with the bottom frame's HTTP connection getting
closed down when pressing the submit button in the top frame.

When the first form in the top frame is submitted an on stop event occurs, the
network library needs to check that the connection belongs to the target of the
form submit. In this case, we're submitting in the top frame, but the connection
associated with the bottom frame gets closed. It looks like the network library
has no logic to check the frame associated with the on stop request and all
connections associated with the document are closed.

The app works correctly if I manually bypass the CompleteAsyncRead call in
nsSocketTransport::doReadWrite.

Comment 22

[Gagan]

->darin

Comment 23

[benc]

-> http

Comment 24

[Darin Fisher]

> What it looks like is happening is that the when the *Submit* button is
> pressed, a stop request is generated for the http connection (3703f78) this
> causes it to be closed and stop receiving the any information.

from the log, it just appears that the socket reports having been closed by the
server.  there is no indication that necko has decided to close the connection
for the bottom frame.

in fact the connection for the bottom frame appears to be closed after the POST
data is written to the network.

perhaps other browsers reload the bottom frame after a form submission in one of
the frames.  i cannot think of any way that this could be a necko bug.

-> form submission

Comment 25

[Kevin McCluskey (gone)]

nsbeta1+

Comment 26

[Alexandru Savulov]

is not form submission cause the data is posted correctly. i tested this the
folowing way:

- went to http://dragonslair.net/chat/ and entered the alchemist's lab
- logged in as mirkwo
- posted a message("mirkwo : testing mozilla, thx for letting me use this board")
(from here i didn't got any response back, the throbber ran forever)
- started IE and logged in the same chatroom as mirkwo2 and i found the message
posted by mirkwo there.

(log in and you'll find both user's messages there)

I suspect some problems related to frames and targets. Investigating, but not
working on a fix yet, anyone feel free to take over or reassign if you know what
the problem is.

Comment 27

[Vladimir Ermakov]

If you stop, and then view frame source, you will see the last coment, but the
frame is not updated because the old page is still trying to load I guess. This
has to do with pages that dont finish loading.

Comment 28

[Alexandru Savulov]

we are loading here two frames at the same time: the upper one is called  BANNER
and the lower one is called BODY.  I dumped the the TCP traffic for the loading
of the frames and i noticed that the server is not sending the a continuation
packet for the BODY with the FIN flag set.
I don't know how they do that but it must be some kind of sleep or something,
their response is that they run a "chat server" (whatever that is) and is not
one of the major servers. if one looks at the source of the BODY frame, the end
tags are missing. is interresting that IE does not complain about that and is
finishing the layout of the page. I tracked the sequence numbers of the traffic
generated with IE and it does not receive a FIN packet either, but for some
reason the throbber does not run anymore and the page is reflown with the
available data (in a previous comment, Darin sais that the server choses to
close the socket intentionally so that might explain why IE does not thorb
anymore). will spend some more time with this but not too long though.

removing nsbeta1+ for the reasons mentioned above. (maybe also reassign to necko
since is not really form submission)

Comment 29

[Vladimir Ermakov]

->

Comment 30

[Doug Turner (:dougt)]

reassigning to darin.

Comment 31

[Darin Fisher]

-> suresh for investigation

Comment 32

[Samir Gehani]

adt: nsbeta1-

Comment 33

[Jim Shockey]

Will this problem ever be addressed?  I have been a loyal user of mozilla since
version 3.1 and now I'm forced to us Internet Explorer because of this bug.

Comment 34

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre