Bug 13352 – REGRESSION: Gmail hangs on send message

• Component: Page Loading
• Status: RESOLVED FIXED

[Ruben Bakker]

When I send a Gmail message by pressing the "Send" button, the message is not delivered and the status message (right upper corner) stays on "Sending...". A second click can resolve the problem. However, this is unusable, as there may be a big upload (file attachments) going on. This does not happen always, but often: maybe about one out of ten to 20 times. 
See attached screenshots (gmail and activity window) for how it looks like for the user. 
The problem cannot be reproduced with Webkit 419.3. 

Steps to reproduce:
1) start Webkit.app
2) goto mail.google.com and log in.
3) click the link "compose message"
4) fill "To", "Subject" and message text
5) click the "Send" button
6) goto 3) until you see the infinite "Sending..." status message

I did some analyzing, and I have tried to find out why it is happening:

Console log:
I have started a debugger in the WebCore project. There are not errors shown in the console log. 

Webkit:
In my application I have registered a FrameLoadDelegate. When the faulty send happens, the delegate gets called with webView:didStartProvisionalLoadForFrame: but never with the webView:didCommitLoadForFrame:, webView:didFailProvisionalLoadWithError:forFrame:frame or webView:didFailLoadWithError:forFrame:

ethereal:
I have traced the network traffic with "ethereal". When you send a Gmail message Webkit sends a POST and then waits for a response. The POST is always sent, but there is no Google response when the problem happens. I have attached this ethereal information always for the OK and PROBLEM case: Screenshots of network traffic, text file of POST, and the original ethereal files.

Spoofing as FF:
I tried spoofing as Firefox to rule out a problem on the Google servers. It was more difficult to reproduce the problem, but it still happened.

Hint:
It seems to happen more often just before, during, or just after a Gmail autosave.

[Ruben Bakker]

Created attachment 14036 [details]
The Gmail window when an infinite "Sending..." is shown

[Ruben Bakker]

Created attachment 14037 [details]
Contents of activity window while the infinite "Sending..." is shown

[Ruben Bakker]

Created attachment 14038 [details]
Ethereal screenshot of network pakets when send is OK

[Ruben Bakker]

Created attachment 14039 [details]
Ethereal screenshot of network pakets when send is hanging

[Ruben Bakker]

Created attachment 14040 [details]
Contents of the POST network paket when the send is OK

[Ruben Bakker]

Created attachment 14041 [details]
Contents of the POST network paket when the send is hanging

[Ruben Bakker]

Created attachment 14042 [details]
Original ethereal file when send is OK

Open in ethereal (use MacPorts or Fink)

[Ruben Bakker]

Created attachment 14043 [details]
Original ethereal file when send is hanging

[Brady Eidson]

Hello Ruben,

You state this is a regression, but don't mention which revision of WebKit you were using when you encountered these results.

Using the WebKit nightlies at nightly.webkit.org could you found out between which two revisions this broke, if it was indeed a recent regression?

Thanks!

[Ruben Bakker]

(In reply to comment #9)

Hello Brady,
I tested different versions between 20648 (4/1/07) and 20895 (4/15/07) with the same results.
When trying 20895 today: 
- Pressing "Save now," waiting for the "Draft saved ...." message beside the button and then immediately pressing Send provoked the error "Sending...", too.
- I noticed that the same problem can be reproduced with "Save now", I got an infinite "Saving..." notification.
I do not know when the regression happened. Webkit shipping with 10.4 (tiger) works, Webkit nightly between 20648 to 20895 don't.
HTH
Kind regards,
Ruben

[Brady Eidson]

Ruben,

http://nightly.webkit.org/ has nightly builds of Webkit dating all the way back to October 2005.  It might end up being valuable if you could narrow down when this actually broke - starting with the very earliest nightly, then binary searching from there.  I suspect it might not take too long to find out when it broke!  :)

[Ruben Bakker]

(In reply to comment #11)
Hi Brady,
3/8/07 r20057 works, I was not able to reproduce the bug.
3/9/07 r20077 is so bad, the Sending.../Saving... problem happens on first click!
HTH
Ruben

[Gregory Block]

Sidenote....

1) this works for me, right now.
2) This might be because The Google had gmail problems on that particular day, and we were all encountering this... on pretty much every browser.  I, too, thought it might have been a nightly build but the reality probably has more to do with it being 4/15, when gmail was a bit borked.

I'd ask the original author to retest his browser on this - I'll bet this isn't actually happening anymore.

[Mark Rowe (bdash)]

Ruben, can you please retest with the latest nightly to confirm Gregory's suspicions?

[Ruben Bakker]

(In reply to comment #14)
I will re-test as soon as I can. 

Please keep in mind that the error could be reproduced on different days. I still get user bug reports for my application (using Webkit nightly) with the same kind of error. And no problems on same days could be reproduced with build #20057 and the Webkit installed on Tiger. If it was a server problem, I would have experienced the problem in all browser...

[Ravi Grover]

I see this all the time too.  Have to switch to regular Safari and then everything works fine

[Andres Gonzalez-Mancera]

I have the exact same problem and can verify that this is still happening with the current nightly build.

[Ruben Bakker]

I have re-tested with the very latest WebKit nightly (#21448): I still get the infinite Saving... or Sending... as described in the bug. 

This is the easiest way to reproduce it:
1 compose a new message
2 write some text
3 save
4 repeat 2 + 3 until you get an infinite "Saving..." status message.

If the Google servers are at fault you get a "Oops the server was unable to perform..." after some time. In my case there is nothing, WebKit just shows the infinite red status message.

PS: In fact I have re-tested three weeks ago. I discovered today that my bug comment is missing - I somehow didn't commit it... 

[Rachael Worthington (cheers)]

I see this in OmniWeb off of a recent webkit rev as well

[Viktor Szathmary]

Consistently reproducible with several latest webkits. Sending e-mail in GMail is extremely unreliable - and only w/ WebKit. Other browsers (incl. Safari) work perfectly at the same time. Definitely not an issue with the GMail service itself.

Would love to see this fixed.

[Kevin McCullough]

I can dupe this fairly easily, and the reduction information here is very helpful.  I'll start looking at this.

[Ruben Bakker]

(In reply to comment #21)
> I can dupe this fairly easily, and the reduction information here is very
> helpful.  I'll start looking at this.
> 
This is great news! If I can help you by providing more information or do some testing, just let me know. 

[Kevin McCullough]

I suspect the culprit checkin is related to 20074.  However I synced with the tip of tree and of course can no longer dupe with my previous steps.  I'll keep trying but can others try to find a set of steps to dupe this on TOT?

[Ruben Bakker]

(In reply to comment #23)
> I suspect the culprit checkin is related to 20074.  However I synced with the
> tip of tree and of course can no longer dupe with my previous steps.  I'll keep
> trying but can others try to find a set of steps to dupe this on TOT?
> 

As mentioned in comment #11 I found #20057 to be the last working build:
3/8/07 r20057 works, I was not able to reproduce the bug.
3/9/07 r20077 is so bad, the Sending.../Saving... problem happens on first
click!

[Kevin McCullough]

Have you tried r21970 or after?  I can't seem to dupe anymore.

-Kevin

(In reply to comment #24)
> (In reply to comment #23)
> > I suspect the culprit checkin is related to 20074.  However I synced with the
> > tip of tree and of course can no longer dupe with my previous steps.  I'll keep
> > trying but can others try to find a set of steps to dupe this on TOT?
> > 
> 
> As mentioned in comment #11 I found #20057 to be the last working build:
> 3/8/07 r20057 works, I was not able to reproduce the bug.
> 3/9/07 r20077 is so bad, the Sending.../Saving... problem happens on first
> click!
> 

[Andres Gonzalez-Mancera]

I have had problems even with today's build. It seem to me that it happens mostly when you take longer composing an email.

(In reply to comment #25)
> Have you tried r21970 or after?  I can't seem to dupe anymore.
> 
> -Kevin
> 
> (In reply to comment #24)
> > (In reply to comment #23)
> > > I suspect the culprit checkin is related to 20074.  However I synced with the
> > > tip of tree and of course can no longer dupe with my previous steps.  I'll keep
> > > trying but can others try to find a set of steps to dupe this on TOT?
> > > 
> > 
> > As mentioned in comment #11 I found #20057 to be the last working build:
> > 3/8/07 r20057 works, I was not able to reproduce the bug.
> > 3/9/07 r20077 is so bad, the Sending.../Saving... problem happens on first
> > click!
> > 
> 

[Kevin McCullough]

I had that sense too.  For my previous reproducible cases I would start drafting an e-mail, then wait for the autosave to happen, then enter a lot of information (usually through a paste).  And it would always hit the sending issue.  Now those steps aren't working for me.  I just tried typing a long e-mail that took about 5 minutes to fully draft and still didn't hit it.

If someone has reproducible steps with TOT please let me know.  I'll keep looking at it.

-Kevin

(In reply to comment #26)
> I have had problems even with today's build. It seem to me that it happens
> mostly when you take longer composing an email.
> 
> (In reply to comment #25)
> > Have you tried r21970 or after?  I can't seem to dupe anymore.
> > 
> > -Kevin
> > 
> > (In reply to comment #24)
> > > (In reply to comment #23)
> > > > I suspect the culprit checkin is related to 20074.  However I synced with the
> > > > tip of tree and of course can no longer dupe with my previous steps.  I'll keep
> > > > trying but can others try to find a set of steps to dupe this on TOT?
> > > > 
> > > 
> > > As mentioned in comment #11 I found #20057 to be the last working build:
> > > 3/8/07 r20057 works, I was not able to reproduce the bug.
> > > 3/9/07 r20077 is so bad, the Sending.../Saving... problem happens on first
> > > click!
> > > 
> > 
> 

[Ruben Bakker]

I tried #21970 (todays  build) and was able to reproduce the hanging save problem. (see instructions in comment #18 for reproducing the "hanging save").

[Kevin McCullough]

I think I got it.  The form data boundary is constructed via base64Encode() which can include the AlphaNumeric characters as well as + and /.  Whenever the / char is included in the boundary gmail seems to hang, or rather does not ever respond.  The reason clicking send or save again causes the mail to work, is that the new random boundary generated probably doesn't have the / character in it.

On the W3C's site it said it used RFC 2045 for boundary standards (same as MIME types), which in tern sited RFC 2046, which says that the boundary can be made up of 7bit ASCII characters including numbers, alpha characters, ',(,),+,_,,,-,.,/,:,=, and ?.  This set includes / which is the problematic character.

By my testing the following characters also caused the non-reply from Google, although not all of these chars are legal according to RFC 2045: #, /, &, *, (, ), =, [, ], {, }, \, :, ", ,, ., <, > and ;.

I'll contact Google to double check my findings, but in the mean time I'll implement a new getUniqueBoundaryString() functions that returns only AlphaNumeric characters.

-Kevin

[Kevin McCullough]

man I can't spell

-Kevin

[Kevin McCullough]

fixed in r22013

[Ruben Bakker]

I have done a quick test with nighly #22014 and I was not able to dup the bug. I will continue to use this build and see if is OK in the long run. 

Kevin: Thanks for fixing this!!

[Ruben Bakker]

Test update: I have sent about 40 mails today and it worked every time...

[Viktor Szathmary]

(In reply to comment #33)
> Test update: I have sent about 40 mails today and it worked every time...
> 

I can confirm this as well, r22014 functions perfectly in this regard.

Thanks for fixing this!

[Kevin McCullough]

Great I'm glad this is working!  It was annoying me as well.

[Mark Malone]

rdar://5314478

[David Kilzer (:ddkilzer)]

Adding keyword for future searches:  WebKitFormBoundary