Ken Beal Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

If I'm downloading something (on my 56k modem), and then try to click a link or
open a page, about 1/3 of the time I'll get a blank page, and Mozilla will state
"Done" at the bottom.

It also does this if I click on "Submit" to post a reply at Slashdot.  The most
recent time (just now) I had to click "Submit" 3 times before it actually
submitted my post.

Reproducible: Sometimes
Steps to Reproduce:
1. Start a download (or more than one).
2. Try to use Mozilla.



Actual Results:  About 1/3 of the time, I get a blank page.

Expected Results:  It should have actually gotten the page, or given me an error
"network busy, try again later" or something.  Of course, just because the modem
is responding slowly to Mozilla doesn't mean Moz should timeout.

I am submitting this as "Critical" because, as specified, it is causing me to
lose data.  Either data that I'm expecting to come in (a page load) or data that
I'm expecting to go out (a Slashdot post).

	Matthias Versen [:Matti]
	Comment 1 • 23 years ago

-> Networking:Http
( i saw such effects on a very busy 64kbit dialup)

	Michael Lefevre
	Comment 2 • 23 years ago

I used to see this with older versions of Mozilla, but haven't done for a while.

reporter (Ken): can you reproduce this problem with a recent version of mozilla
(for example, 1.1alpha)? if so, please comment again with details. if not,
please resolve this report as WORKSFORME. thank you.

	Ken Beal Reporter
	Comment 3 • 23 years ago

bugzilla.mozilla.org@michaellefevre.com: I removed 1.0final (and deleted the
"D:\Program Files\mozilla.org" tree) and installed 1.1a (build 2002061104). 
Still Win2K server etc.

My first attempt at opening 11 /. stories (to be as consistent as possible with
my intial problem) opened all but one successfully.  The one it didn't open
"successfully" was apparently completely loaded, it just didn't display the /.
tab icon (all others did).

Then I remembered that I had turned pipelining on.  Checking my options, it
remembered this, so I turned it off and tried again.

(Note: the one that was missing [*] the tab icon had it after they finished
loading.)
(Note 2: got a "document contains no data" popup which went away as soon as I
got to the [*] in the previous Note: and hit "space" -- aside, I HATE IT WHEN an
app steals focus.  Couldn't it just flash the Task Bar to let me know it needs
attention?)

There was only one tab which did not load completely for the non-pipelined test,
and that was a different one than had the missing /. tab icon.

If I had to guess, I'd bet the problem is in the non-pipeline code path.  I
don't know what would cause a tab icon to not be displayed, but that's the only
problem there.  It's still "loss of data" but it's trivial -- the "document
contains no data" error is far worse.

To finish addressing your comment, I cannot resolve this as WORKSFORME since it
doesn't -- in either of the code paths (pipeline or not).

I just noticed that I'm testing a different symptom (from bug 152193, which I
entered recently).  Can someone link this comment to the other bug as well, or
do I have to enter it manually?  This applies to both bugs, and the bugs overlap
but are NOT sub/super-sets -- one (this) deals with losing form data, the other
(bug 152193) deals only with opening multiple pages at once.


Finally, after installing 1.1a I found that closing multiple tabs is AMAZINGLY
faster -- they now disappear in real-time (1.0 GHz Athlon) whereas just a couple
minutes ago (on 1.0final) it took up to 2 seconds to close each tab, either
clicking the [X] or typing Ctrl+W.  This has nothing to do with either bug, but
there's no efficient way to use Bugzilla to say "Thank you!"  So, inefficiently,
"Thank you!"  ;-)

	Michael Lefevre
	Comment 4 • 23 years ago

Ken, splitting your comment up a little...

not displaying the tab icon - sounds like a different bug, which i think is
already filed, about staying in the "transferring data" state when it's actually
finished.

the "document contains no data" - not sure this is really a mozilla bug. it's
telling you that mozilla got no data back from the server, in this case probably
because the packets on that connection couldn't get down the very busy line.
that behaviour will happen with most internet apps - for example, if i set my
SMTP program here to try and send 20 messages at once, most of the connections
will time-out without getting anywhere. when it was failing without an error (as
you originally reported), that was a mozilla bug, but I think that has gone now.

seems to me that this and bug 152193 are basically the same thing - one is
failing to do a form POST when the connection is saturated, the other is failing
to do a GET when the connection is saturated.

how do other programs behave when you try this kind of thing (e.g. open 11 pages
in mozilla and then try collecting email, or try opening 11 pages in IE or
another browser)?

and I'm afraid you can't add the same comment to two bugs. you could put a link
in (to http://bugzilla.mozilla.org/show_bug.cgi?id=141624#c3 ), but I think it
would be better to add a concise comment in the other bug separately.

	Boris 'pi' Piwinger
	Comment 5 • 22 years ago

Is this still a problem in 1.1 or later?

I never see it on Win98SE with a 56k modem.

pi

	Michael Lefevre
	Comment 6 • 22 years ago

I can still make it happen, but I'm still not sure it's really a bug that can be
fixed.

I just did it with 1.1 and a 64K ISDN line.  Started a download going with
Getright (which was filling up the line happily), then switched to mozilla, went
to slashdot, opened a dozen slashdot stories in different tabs, and sure enough,
2 of them came back with "document contains no data".  refreshing them once
everything else had calmed down worked fine. Using a ping tool to something just
beyond the other end of the line showed about 70% of test packets being dropped.
 I don't know how mozilla works network-wise, but I guess the way to fix it
would be to make sure that mozilla doesn't have more than a couple of
connections (to anywhere) open at the same time, but obviously that would suck
boulders on a high bandwidth connection.

	Michael Lefevre
	Comment 7 • 22 years ago

can still be made to happen in 1.2.1, but I'm still not sure that this is a bug
that can be fixed. confirming anyway so that someone else can decide.

don't think dataloss applies here - forms submitted will be available by going
"back", incoming data is not lost as it's still on the remote server. the fact
that the data fails to get transferred is not a "loss" in the dataloss sense, IMO.

	Darin Fisher
	Comment 8 • 22 years ago

i'm in the process of rewriting the socket transport (see bug 176919) with a
focus on getting the multithreading right from the ground up.  perhaps that
patch will help eliminate this bug.

	Darin Fisher
	Comment 9 • 19 years ago

-> default owner

	Wayne Mery (:wsmwk)
	Comment 10 • 13 years ago

(In reply to Darin Fisher from comment #8)
> i'm in the process of rewriting the socket transport (see bug 176919) with a
> focus on getting the multithreading right from the ground up.  perhaps that
> patch will help eliminate this bug.

bug 176919 is fixed.

do you still see this problem?

	Phoenix
	Comment 11 • 13 years ago

Resolved per whiteboard