Closed Bug 117363 Opened 23 years ago Closed 23 years ago

Can't send mail through Hotmail

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: bugzilla, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(6 files)

Log file
250.82 KB, application/octet-stream
Details
New log file
502.57 KB, application/octet-stream
Details
Log file #3
253.92 KB, text/plain
Details
Packet log from Mozilla attempt
2.48 KB, text/plain
Details
Packet log from IE success
11.94 KB, application/octet-stream
Details
IE log 2
2.93 KB, text/plain
Details 
Build ID: 2001122803 comm.

Just like bug 117361 but with a different high profile site. Woo!

Build ID: 2001122803 comm.

A number of 6.2 users have reported an inability to send mail through Hotmail. 
I can confirm that this problem still exists in new nightlies.  I found 
other Hotmail-related issues reported, but couldn't find one about sending.

The browser just hangs (throbber/status messages going) when trying to send.
Nominating for machv.
URL: http://www.hotmail.com/
Keywords: nsbeta1
cc'ing darin
also investigating this asap.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.8
-> me
Assignee: neeti → darin
Status: ASSIGNED → NEW
WFM too (linux + windows)
*** Bug 116004 has been marked as a duplicate of this bug. ***
can those who have seen this bug please test it again using a recent nightly
build?  thx!
marking WORKSFORME... please reopen this bug if you can reproduce it using a
recent nightly build.  thx!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
I still see this.  So does the reporter of 120935.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** Bug 120935 has been marked as a duplicate of this bug. ***
blake: can you capture a HTTP log while exercising this bug?  set the following
env vars:

 set NSPR_LOG_MODULES=nsHttp:5
 set NSPR_LOG_FILE=http.log

if you can attach the HTTP log, i might be able to better understand the cause
of this problem.  thx!
Hmm...and now, in today's build, I can't reproduce :-/  I suspect haphazard 
flakiness, but I'll reclose for now I guess.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
*** Bug 123040 has been marked as a duplicate of this bug. ***
reopening :-(
(dupe with a recent build)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
oseberg: we are having trouble reproducing this bug.  can you please follow the
instructions in comment #11... it would help us very much!!  thx in advance!
Status: REOPENED → ASSIGNED
Keywords: helpwanted, qawanted
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Attached file Log file — 
This was created with 2002020406 on Win2k.

When trying to send the browser appears to be transfering, "transfering datat
from..." etc, but never finishes. It doesn't appear to time out either, but
maybe I just didn't wait long enough.
mark: thanks for the log.  can you also attach the email you were trying to
send?  does this bug happen every time?

from the log it appears that mozilla is waiting for the server to respond.  it
is not getting any response.  it's looking like a server problem, but if people
are seeing this behavior consistently with mozilla and _never_ with other
browsers, then obviously there must be something wrong with mozilla.  but,
unfortunately this log file is not showing any problem on the part of mozilla.
Attached file New log file — 
I've noticed that if you wait about 3 minutes, Mozilla will report "Document
done" and so I've attached a new log that includes that portion. Maybe this
will be of some use.

Yes, this bug is always reproducible with Mozilla, but I've never seen it on
the few times I've tried with IE. I'm not sure how I could go about attaching
the email, as it was never sent to begin with. I could attach an equivalent one
sent using IE, or perhaps just give you any info you needed.
mark: thanks for the new, complete http log file.  can you also try this:  can
you try creating a brand new profile?  just run mozilla with the -ProfileManager
command line option to bring up the profile selection dialog.  it's perhaps
wishful thinking, but i wonder if you didn't happen to download some nightly
build that corrupted your profile in some way.
the new log file doesn't tell me anything new.  it just looks like the server
connection is timing out after it sends a 100 continue.  perhaps mozilla is not
properly sending the post data, causing the server to think the data hasn't been
sent.  unfortunately, the log file doesn't indicate what was sent or what wasn't
sent for that matter.
Attached file Log file #3 — 
Done with a brand spanking new profile, as requested.

I also noticed that it seems to always take 180.xxx seconds for the document to
complete. Don't know if that's helpful.
mark: so, same problem as before.  any chance you could generate a network
packet trace?  would be good to compare IE to mozilla for example.
Darin: I don't know to do that.
mark:

ngrep is a simple network packet tracer... it is available at
ngrep.sourceforge.net.  you run it from the command line.

eg.

  c:\> ngrep port 80 > packet.log

if you could install this program and use it to capture a packet log of mozilla
and a separate packet log of IE that would be very very helpful!  it may be the
only way for me to solve this bug at this point.
As requested.
As requested as well. I hope this helps.

Who knew reporting bugs could be such a learning experience?
mark: thanks for the network traces!!  but, it looks like the IE trace doesn't
correspond to the same thing.  there isn't a POST request to /cgi-bin/premail
anywhere.  despite that i think i understand now what is going on.  the
content-length header in mozilla's POST request is incorrect.  the actual length
of the data is less that that specified, which of course causes the web server
to wait until all of the data arrives.  and it never arrives!

this must be a problem with the code generating the form POST data.

*** This bug has been marked as a duplicate of 117361 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
spam: meant to dup in the other direction
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 117361 has been marked as a duplicate of this bug. ***
If this is a size problem, it should be fixed with bug 120682, landing Real Soon
Now.  Setting dependent.
Depends on: 120682
Status: REOPENED → ASSIGNED
Attachment #68004 - Attachment mime type: application/octet-stream → text/plain
the content-length as reported to the server appears to be equal to 64 +
real_content_length.  looking at the code in nsFormSubmitter.cpp it is not
obvious how this could be the case.  inspecting the data and comparing it to a
successful POST to /cgi-bin/newmail suggests that the data is truly intact.  so
something is corrupting the content-length header :-(
mark: could you please re-generate the IE packet trace.  it does not seem to
correspond to submitting mail from hotmail.  without the IE packet trace, it is
difficult to determine where exactly the problem is with the data mozilla is
sending.  thx!!
Attached file IE log 2 — 
Hope it worked this time... Yeah i'm not quite sure what I was doing last time.
mark: i just realized that you are connecting via a proxy server!  that could
explain why i'm not able to reproduce this bug!  investigating...
Attachment #68081 - Attachment mime type: application/octet-stream → text/plain
mark: from your IE log it appears that IE is configured to use a webproxy, but
from your mozilla log, it appears that mozilla is not configured to use a
webproxy.  can you test each w/ the same internet connection?  does mozilla work
if you connect to your webproxy?

i tried this with a webproxy and still couldn't reproduce the problem :(
so jeeva attached some tcpdump logs to bug 117361 demonstrating the problem on
mail.yahoo.com.  interestingly, the Content-Length header advertized is also 64
bytes too large.  after inspecting the data, and comparing it to that sent by
IE, I think I can determine that mozilla isn't dropping bytes on the floor. 
instead, it simply isn't sending the right Content-Length header.  time to
figure out why.
Darin, you are correct, I just verified that.. 

I am wondering why IE is sending the "Context-Length" in the POST request 
packet and Mozilla is sending it in "Continuation" (2nd) HTTP packet.

I have also noticed IE sending "Mozilla/4.0" as User-Agent.. What does IE has 
to do with Mozilla... 

Sorry for asking questions here, but I am just eager to know.
the packets actually correspond to how the data is buffered on the client.  on
mozilla, the content-length header is buffered with the data, whereas on IE the
content-length is buffered with the other headers.

IE's useragent stems from the ol' days when mozilla/4.0 was the web standard
user agent.
Darin: I'm not sure what my proxy is to be able to connect through it with
Mozilla, nad I can't quite figure out how to not connect through it with IE. Is
this still a relevent point? If so I can work at little more at it.
mark, jeeva: how fast is your network connection?  it's possible that this bug
might only be triggered at certain network speeds.  thx!

mark: i think the proxy setting is irrelevant.  thx anyways.
*** Bug 112613 has been marked as a duplicate of this bug. ***
Darin: I have a cable modem.
Just so you know, the patch for bug 120682 is getting really closed to being
finished. That changes next to all code that is involved with formsubmission. I
can't guarantee that it fixes this bug, although we are of course hoping it will.
*** Bug 122058 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1 → nsbeta1+
That did in fact fix it.  The problem was length calculation on the email (it
set Content-Length wrong).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
jkeiser: are you sure?  were you able to reproduce the problem before your
checkin?  i thought you weren't able to.  i'd really like to hear from mark and
jeeva before closing this.

mark, jeeva: can you guys try out a recent nightly build and confirm that this
bug has been fixed?  thx!
No, I didn't try it out before my checkin.  I just now created an account.
WFM! Build # 2002022203
mark: awesome!!!  i'm so releaved :-)
I agree, this works for mail.yahoo.com as well.
Thanks for the fix
It works for me too :) 
*** Bug 129657 has been marked as a duplicate of this bug. ***
*** Bug 129651 has been marked as a duplicate of this bug. ***
*** Bug 122262 has been marked as a duplicate of this bug. ***
Since this is nsbeta+, it needs the correct home.

Should this go to form submission?
Component: Networking → Form Submission
verifying on build 2002-04-10-03-trunk
Status: RESOLVED → VERIFIED
Keywords: qawanted
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: