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.
Created attachment 14036 [details] The Gmail window when an infinite "Sending..." is shown
Created attachment 14037 [details] Contents of activity window while the infinite "Sending..." is shown
Created attachment 14038 [details] Ethereal screenshot of network pakets when send is OK
Created attachment 14039 [details] Ethereal screenshot of network pakets when send is hanging
Created attachment 14040 [details] Contents of the POST network paket when the send is OK
Created attachment 14041 [details] Contents of the POST network paket when the send is hanging
Created attachment 14042 [details] Original ethereal file when send is OK Open in ethereal (use MacPorts or Fink)
Created attachment 14043 [details] Original ethereal file when send is hanging
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!
(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
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! :)
(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
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.
Ruben, can you please retest with the latest nightly to confirm Gregory's suspicions?
(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...
I see this all the time too. Have to switch to regular Safari and then everything works fine
I have the exact same problem and can verify that this is still happening with the current nightly build.
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...
I see this in OmniWeb off of a recent webkit rev as well
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.
I can dupe this fairly easily, and the reduction information here is very helpful. I'll start looking at this.
(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.
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?
(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!
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! >
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! > > >
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! > > > > > >
I tried #21970 (todays build) and was able to reproduce the hanging save problem. (see instructions in comment #18 for reproducing the "hanging save").
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
man I can't spell -Kevin
fixed in r22013
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!!
Test update: I have sent about 40 mails today and it worked every time...
(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!
Great I'm glad this is working! It was annoying me as well.
rdar://5314478
Adding keyword for future searches: WebKitFormBoundary