141451 - First a window "Document contains no data" is shown, then the page is normally loaded

Status: RESOLVED WORKSFORME

(Core Graveyard :: Networking: FTP, defect, P2)

Description

[Jens Müller (:tessarakt)]

1. Go to ftp://ftp.ccc.de/pub/chaosradio/
2. Click on cr10

Actual results:
- a message box with caption "Alert" and text "The document contains no data" is
shown.
- after pressing ok, the subdir is loaded normally.

Expected result:
- The subdirectory is loaded normally, without showing the alert.


The same alert appears when pressing back in the subdirectory.

Comment 1

[R.K.Aa.]

Please always include build ID in bug-reports

Comment 2

[Jens Müller (:tessarakt)]

2002050110

Comment 3

[gabriel]

Dupe of bug 137965 (which looks like it may need reopening) ?

Comment 4

[Kathleen :Brade]

Is it just me or does the build ID seem suspicious when compared to the
timestamp on the comment?

I do see this problem on my Debug Mac Mozilla build from today.

Comment 5

[Jens Müller (:tessarakt)]

Dunno. Maybe is has to do with timezones?

I did not build it, it is the Debian package built by Takuo KITAME.

Comment 6

[Quinn Fazigu]

ftp://ftp.netsville.com/pub/hazel/

Hit it, see the "Document contains no data" error.

Linux, build ID 2002043010.

Comment 7

[gabriel]

Confirming with Linux build 2002050109

Comment 8

[R.K.Aa.]

both the URL in url-field as well as in comment 6 WFM, XP, 2002050108.

Comment 9

[gabriel]

Linux only ?

Comment 10

[djk]

I was seeing this dialog appear frequently also on win98.

Then I created a new profile, and have not seen it since.

Have you tried a new profile?

[OT] I also noticed strange problems with mozilla requesting pages from the
wrong host and strange non-updating problems with the URL bar before the new
profile also... Now everything's peachy.

Comment 11

[Bradley Baetz (:bbaetz)]

'Joy'. Another server interaction thing...

Comment 12

[Quinn Fazigu]

A fresh profile didn't change it for me.

Just tried the Linux 2002031312/0.9.9 build on my home box over DSL using X11,
and it doesn't have the problem.

Also doesn't occur on Win98 2002041711/1.0RC1.

Comment 13

[djk]

I managed to get the popup using the method in bug 135182 comment 10.

After that, I got the dialog a few more times on other sites, but not nearly as
much as before I made a new profile...

Comment 14

[Jens Müller (:tessarakt)]

gabriel: Nope, bug 137965 deals with HTTP networking.

Comment 15

[Rob Hudson]

I'm getting is also when I FTPd to ftp.us.kernel.org.  
Linux, RC3.  Build ID: 2002051009

Comment 16

[Bradley Baetz (:bbaetz)]

I have no time to work on mozilla at the moment, so dougt is taking over FTP

open ftp bugs -> him

Comment 17

[Doug Turner (:dougt)]

I do not see this in 1.1b windows.  Please reopen if this still occurs.

Comment 18

[Quinn Fazigu]

This is still happening in 1.1b on Linux.

Comment 19

[benc]

I'll update all plats soon.

Comment 20

[neeti]

I do not see this on my win2000 or linux trunk build.

Comment 21

[neeti]

me

Comment 22

[neeti]

This works for me with win2k and linux trunk and 1.0 branch builds.

Comment 23

[Quinn Fazigu]

I still see this.

Mozilla 1.2a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020911

I'm testing on ftp://ftp.netsville.com/.

I downloaded the tar.gz above, removed my entire ~/.mozilla directory, ran the
new one, and I still see the "Document contains no data."

Comment 24

[neeti]

ok, I can reproduce this with ftp://ftp.netsville.com/ on linux trunk and 1.0
branch builds. This site works fine with win2k trunk and 1.0 branch builds.
Updating URL in the bug

Comment 25

[Doug Turner (:dougt)]

try the patch in this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=162326 

Comment 26

[neeti]

doug: I applied the patch to the 1.0 branch, but I still get the  alert dialog
with "The document contains no data". In both cases( before and after the patch)
the subdirs would load. The difference I found after applying the patch is that
the throbber stops after loading the subdirs, whereas before, it would still
keep throbbing even after loading the subdirs.

Comment 27

[Doug Turner (:dougt)]

i see.  I guess this is a seperate bug.

Comment 28

[Jean-Pierre Melkonian]

WFM with all the links above, with MacOS 9.1 Build 2002091108

Comment 29

[benc]

UPDATE:
using current URL, Linux-only, Mozilla 1.1.

Anyone else seeing it elsewhere now?

Comment 30

[neeti]

Attachment: proposed patch

doug: could you please review the patch.

Comment 31

[neeti]

I have tested the patch on a number of sites on
mozilla/netwerk/protocol/ftp/test/frametest/index.html

Comment 32

[Doug Turner (:dougt)]

you should remove the other SetRetrying.

Comment 33

[neeti]

Attachment: revised patch

Removed the other SetRetrying

Comment 34

[Doug Turner (:dougt)]

Comment on attachment 99093 [details] [diff] [review]
revised patch

add a comment above where you call SetRetrying.  State something like. 

Bug: 141451 - We call this before receiving the error because on some systems
the error closes the mDRequestForwarder data socket faster than we can process
the control channel’s error code.


r=dougt.

Comment 35

[neeti]

Attachment: revised patch with comments added

Comment 36

[Doug Turner (:dougt)]

Comment on attachment 99110 [details] [diff] [review]
revised patch with comments added

r=dougt

Comment 37

[Doug Turner (:dougt)]

Comment on attachment 99110 [details] [diff] [review]
revised patch with comments added

oh... add a space between "bug" and 141451

Comment 38

[neeti]

Attachment: between "bug" and 141451

Comment 39

[Darin Fisher]

Comment on attachment 99111 [details] [diff] [review]
between "bug" and 141451

sr=darin

Comment 40

[Bradley Baetz (:bbaetz)]

This is actually a Feature. The problem with closing the data socket there is
that you then get interactions with systems which do stuff in a different order,
or return teh same port from another PASV response, or just don't like what we
do. You can't set us up for the retry state unless we are actually retrying this
transaction (which won't be the case for a sucessful RETR, ever)

I suspect that this is the cause of bug 169002 and friends - since mRetrying is
true, the onstop is never sent (in fact, the onstart isn't either, which
may/will cause other problems)

The real problem here was that the dummy close sent errors on to the caller. It
_may_ be suffieient to use a PR_FALSE argument instead of PR_TRUE, but I suspect
not, especially since the other SetRetrying was pulled out. I'm not sure about
what the bug here is, but since I do not see this on a linux trunk build with id
2002081318 (ie before this patch), I can't do much to help...

FTP log output (whcih is unfortiuantely not enabled in debug builds yet) from a
build without this patch which is seeing this may be helpful. |TestProtocols
-verbose| output is even better, if you can reproduce it with that test program

This may be related to bug 167820, maybe.

Comment 41

[Doug Turner (:dougt)]

hmm.  I don't think i follow what your saying.  The change moved the set of
mRetrying to before we send RECV.  The reason is that, on linux, we get then
OnStopRequest for the data channel before we have a chance to check the control
status.

Maybe we should rest the mTrying in the handling of RECV back to false if there
are no errors...

Comment 42

[Bradley Baetz (:bbaetz)]

> The reason is that, on linux, we get then OnStopRequest for the data channel
> before we have a chance to check the control status.

Thats not quite true. We may, sometimes, get that, depending on the remote
server, speed of the connection, and phase of the moon.

Because of the DelayedOnStart stuff, the data channel which will nnd up being
incorrect never sends the onstart to the consumer. It has no data, so it never
calls ODA.

Note the call to mDPipeRequest->Suspend(). That is meant to stop this from
happening, until we resume once we know we have real data (by receving the
response). Unless someone changed the socket code, it should be impossible for
us to get the onstop that early. See bug 129811 for this. As I said, I can't
reproduce this with a trunk build before neeti's change, so I don't know whats
wrong here.

Comment 43

[benc]

*** Bug 170095 has been marked as a duplicate of this bug. ***

Comment 44

[neeti]

I can no longer reproduce the problem for ftp://ftp.netsville.com/ and
ftp://ftp.ximian.com in yesterday's linux trunk builds.
wfm

Comment 45

[Quinn Fazigu]

The popup is gone also for me on Linux build 2002092408.
Thanks, whoever fixed it!  :)