Last Comment Bug 510985 - Twitter submission throbber spins endlessly
: Twitter submission throbber spins endlessly
Status: RESOLVED WORKSFORME
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: P2 critical with 1 vote (vote)
: ---
Assigned To: Ben Newman (:bnewman) (:benjamn)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-17 14:48 PDT by Ben Newman (:bnewman) (:benjamn)
Modified: 2011-12-22 10:57 PST (History)
29 users (show)
shaver: blocking1.9.2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix


Attachments

Description Ben Newman (:bnewman) (:benjamn) 2009-08-17 14:48:45 PDT
When submitting a Twitter update via the web interface, the progress throbber sometimes does not stop spinning, and loading Twitter in a separate tab reveals that the update has not gone through.

Seems to be happening mostly in Firefox 3.5, but sightings have been reported for 3.0.13 as well.  Some users resorting to Safari as a workaround: https://twitter.com/#search?q=twitter%20firefox%20spins%20safari
Comment 1 Ben Newman (:bnewman) (:benjamn) 2009-08-17 15:11:12 PDT
A somewhat superficial finding: attempting to submit an update after modifying |twttr.form_authenticity_token| results in behavior identical to that reported.
Comment 2 Matthew N. [:MattN] (PTO Jun. 29-30) 2009-08-17 15:13:45 PDT
Twitter's response of their status blog was to clear twitter.com cookies.  Maybe this will help narrow down the issue. (From http://status.twitter.com/post/164354669/trouble-updating-in-firefox-try-clearing-your-cookies )
Comment 3 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-17 15:26:21 PDT
Is there anyone on the Twitter development team that we can copy in on this bug? It appears to be something to do with their site and how we implement some cookie or DOM feature, but it would be good to know if our implementation is behaving in a way that it shouldn't, or ..?
Comment 4 Ben Newman (:bnewman) (:benjamn) 2009-08-17 15:35:26 PDT
It would be really helpful if folks who are experiencing the bug could turn on firebug and XmlHttpRequest logging, so that we can find out what the server response code is.  For instace, meddling with |twttr.form_authenticity_token| results in a 403.

Twitter employees could maybe answer this question more quickly from their logs...

A natural workaround would be to do add an "error" callback to these options:

    $.ajax({
        type: "POST",
        dataType: "json",
        url: "/status/update",
        data: P,
        beforeSend: function () {
            G.addClass("loading");
            if (document.all) {
                G.html("    ")
            } else {
                G.css("color", "transparent")
            }
        },
        success: H
    })

For instance:

        error: function() {
            alert("Please clear your cookies and try again!");
            window.location = ("http://twitter.com/?status=" +
                               $("textarea").isCharCounter().val());
        }

Obviously something more user-friendly than alert would be preferable ;)

The existence of this workaround does not imply that the problem is Twitter's, but better error handling couldn't hurt.
Comment 5 David Humphrey (:humph) 2009-08-17 15:51:27 PDT
I'll try to get the response code for you, as I'm hitting this a lot.  I've also seen this in the console when it fails:

Error: no element found
Source File: http://twitter.com/status/update
Line: 1
Comment 6 Ben Newman (:bnewman) (:benjamn) 2009-08-17 16:36:39 PDT
Looks like a similar problem (form_authenticity_token is a rails thing):
http://stackoverflow.com/questions/1201901/rails-invalid-authenticity-token-after-deploy

Doesn't necessarily explain the Firefox specificity; however, if a Firefox user
runs into the issue and switches to another browser, the problem most likely
will not occur in the other browser, because the page load and the form
submission are both more recent than the deployment of new code.
Comment 7 Britt Selvitelle 2009-08-18 01:43:01 PDT
Hey, Britt from Twitter here.

I looked into this a bit this morning. At first we thought it was an issue with MTU limitations over a portion of our network.

Turns out this isn't the case. Looking for a bit more information from our Ops team, which I should be able to pass on tomorrow. I can confirm that the problem is non-deterministic. There are some machines in which an update never completes in Firefox 3.5, whereas on mine it almost always returns successfully.

Looking for more reproducible failure cases. Are there any debugging tools that would help dive deeper?
Comment 8 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-18 04:50:25 PDT
Hi Britt - there are a couple of tools that might help:

Firebug: http://getfirebug.com/releases/index.html
LiveHTTPHeaders: https://addons.mozilla.org/en-US/firefox/addon/3829

You can also join us on irc.mozilla.org in #developers and chat there.
Comment 9 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-18 07:51:02 PDT
Rey suggested I copy in jresig as Twitter is using jQuery ...
Comment 10 Britt Selvitelle 2009-08-18 12:18:42 PDT
I've been looking at the headers both with LiveHTTPHeaders and the Charles proxy. Haven't seen anything strange yet.
Comment 11 Benjamin Smedberg [:bsmedberg] 2009-08-18 12:22:56 PDT
Is it possible that an expiring cookie (but not all the twitter cookies) might cause this behavior? I've noticed that newer builds tend to expire cookies or otherwise log me out of websites a lot more than older builds, and that may be why it's not always reproducible.
Comment 12 Ben Newman (:bnewman) (:benjamn) 2009-08-18 12:25:32 PDT
(In reply to comment #11)
> Is it possible that an expiring cookie (but not all the twitter cookies) might
> cause this behavior? I've noticed that newer builds tend to expire cookies or
> otherwise log me out of websites a lot more than older builds, and that may be
> why it's not always reproducible.

A session cookie expiring while the user has the Twitter web interface open would cause exactly this problem.  Are there any bugs related to this?
Comment 13 Shawn Wilsher :sdwilsh 2009-08-18 12:27:09 PDT
(In reply to comment #12)
> A session cookie expiring while the user has the Twitter web interface open
> would cause exactly this problem.  Are there any bugs related to this?
dwitte should be able to answer that
Comment 14 Ben Newman (:bnewman) (:benjamn) 2009-08-18 12:37:26 PDT
(In reply to comment #10)
> I've been looking at the headers both with LiveHTTPHeaders and the Charles
> proxy. Haven't seen anything strange yet.

Additionally, expiring cookies would look pretty normal on the server side.  When I submit an update while logged out, the response is a 302 redirect to the login page, for which jQuery doesn't fire success() because jQuery.httpSuccess is defined as follows:

  httpSuccess: function( xhr ) {
    try {
      return !xhr.status && location.protocol === "file:" ||
        // Opera returns 0 when status is 304
        ( xhr.status >= 200 && xhr.status < 300 ) ||
        xhr.status === 304 || xhr.status === 1223 || xhr.status === 0;
    } catch(e){}
    return false;
  }
Comment 15 dwitte@gmail.com 2009-08-18 14:00:00 PDT
(In reply to comment #12)
> A session cookie expiring while the user has the Twitter web interface open
> would cause exactly this problem.  Are there any bugs related to this?

Not sure otoh, but I can say that session cookies don't expire (unless you've got some addon that's forcing them to, or they're being evicted because you hit the cookie limit - if you logged in to twitter more than a few days prior, this could be the cause). If the login cookies are stored as non-session cookies, then they will have an expiry date, which you can check in the cookieviewer.
Comment 16 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-08-18 14:02:26 PDT
I have the more-than-a-few-days-prior case, myself.  I stay logged into twitter all the time, often across multiple-day suspends for my desktop.  How can I better detect that this is happening?
Comment 17 dwitte@gmail.com 2009-08-18 16:26:10 PDT
Create a cookie log (https://developer.mozilla.org/en/Creating_a_Cookie_Log), then when you see the spinning, grep the log like so:

grep -A6 "COOKIE EVICTED" cookie.log | grep twitter.com

If that gives you matches then you've got evictions. Natural expirations aren't logged, but that seems an unlikely case unless twitter uses persistent cookies for tracking the login. (Perhaps Britt can comment?)
Comment 18 Britt Selvitelle 2009-08-18 16:54:37 PDT
We do not use persistent cookies for tracking our sessions. See: http://skitch.com/bs/b542w/cookie-information-http-twitter.com-build-20090729211433

When someone has enabled remember-me, we use another cookie that is persistent to work through the authentication stack.
Comment 19 Ben Newman (:bnewman) (:benjamn) 2009-08-19 18:33:45 PDT
Judging from searches for "firefox spins" (and similar), complaints seem to have dropped off almost entirely -- is that a fair assessment, Britt?  Or are you guys still hearing from people?  Any new hunches?
Comment 20 Robert Accettura [:raccettura] 2009-08-19 19:38:51 PDT
Saw this a few hours ago from Michael Arrington:
http://twitter.com/arrington/status/3412633383
Comment 21 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-08-19 19:40:02 PDT
I'm still seeing it too, but I forgot to reset the environment var for cookie logging on the machine in question, so I don't have any more data. :-/
Comment 22 Gordon P. Hemsley [:GPHemsley] 2009-08-19 22:42:55 PDT
For what it's worth, I tend to only see this when Twitter is having connection problems. (It started after the recent DDoS attack.) So, if the page fails to load at some point, and then can load again on refresh, I may not be able to tweet.

I mostly use Twitter via Prism, which is running 3.0.x, if I'm not mistaken. After seeing that post about removing cookies, I physically logged out from Twitter and logged back in, and things seemed to work again. I haven't had a problem since then, I don't think.
Comment 23 Shawn Wilsher :sdwilsh 2009-08-19 22:45:56 PDT
(In reply to comment #22)
> For what it's worth, I tend to only see this when Twitter is having connection
> problems. (It started after the recent DDoS attack.) So, if the page fails to
> load at some point, and then can load again on refresh, I may not be able to
> tweet.
I can confirm that that is when I started to see it as well.  I didn't file a bug because I thought it was related to that.  Haven't seen it in a few days, however.
Comment 24 Britt Selvitelle 2009-08-20 14:14:17 PDT
We have seen this clear up, we think due to upping the MTU in one of our tunneled network segments to 1500.

There are various theories about whether this behavior could return in the future, so I'll comment here if this changes.

Furthermore, if anyone'd like to simulate this effect, email me at britt@twitter.com and I can pass on details on how to replicate the tunnel's behavior.
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-21 05:38:41 PDT
Can we get the instructions posted here, or is it not a modification that Twitter wants to divulge.

Is there any theory as to why the issue was only affecting Firefox 3.5, and only occasionally?
Comment 26 Ben Newman (:bnewman) (:benjamn) 2009-08-21 13:26:44 PDT
(In reply to comment #25)
> Can we get the instructions posted here, or is it not a modification that
> Twitter wants to divulge.

Their best guess, according to email from another Twitter dev (whom Britt put me in touch with) is that the MTU for one part of Twitter's network was accidentally set a little below the usual 1500, to 1492[^1].  We should be able to replicate/investigate those conditions without involving Twitter.

> Is there any theory as to why the issue was only affecting Firefox 3.5, and
> only occasionally?

My guess is that our networking code is somehow more sensitive to changes in MTU than WebKit's.  I've found anecdotal evidence of this on various forums, but I don't think we have a bug filed yet...

-----
[^1]: The year Columbus sailed the ocean blue. Coincidence?!
Comment 27 Christopher Blizzard (:blizzard) 2009-08-21 13:53:56 PDT
The amount of porn spam bots following me on twitter has grown over the last few days and as a result I've been using the block interface a lot.  That's not an ajax-style form, it's just a standard form with a submit/load cycle.  It's also a page that takes a while to finish loading for some reason.

I've seen a _lot_ of "connection reset by peer" errors which makes me think that there's some low-level networking problem on twitter's side.  Maybe the mtu issue is triggering some front end cache server to drop connections before it should?
Comment 28 Ben Newman (:bnewman) (:benjamn) 2009-08-21 14:15:12 PDT
(In reply to comment #26)
> (In reply to comment #25)
> Their best guess, according to email from another Twitter dev (whom Britt put
> me in touch with) is that the MTU for one part of Twitter's network was
> accidentally set a little below the usual 1500, to 1492[^1].
> -----
> [^1]: The year Columbus sailed the ocean blue. Coincidence?!

So it turns out 1492 is not an uncommon MTU by any means; it's recommended for PPPoE/DSL connections, and it's the standard MTU for IEEE 802.3 ethernet.  Pardon my attempt to sugar-coat ignorance with humor!
Comment 29 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-26 09:48:35 PDT
Has this gone away? Is this FIXED? Are people still hitting it?
Comment 30 Christopher Blizzard (:blizzard) 2009-08-26 09:55:49 PDT
I haven't seen any failures to post, but I am still seeing occasional connection resets.
Comment 31 David Humphrey (:humph) 2009-08-26 12:10:07 PDT
I've not hit it again since posting above, and I was getting caught by it frequently before.
Comment 32 Gordon P. Hemsley [:GPHemsley] 2009-09-05 00:14:38 PDT
This seems to be rearing its ugly head again....
Comment 33 Britt Selvitelle 2009-09-05 14:01:39 PDT
Gordon, do you more details?
Comment 34 Gordon P. Hemsley [:GPHemsley] 2009-09-05 14:12:24 PDT
(In reply to comment #33)
> Gordon, do you more details?
Nothing more than I've mentioned in previous comments. Sometimes, when attempting to post a tweet (often a specific reply to another person's tweet, though that may be a coincidence), I get the loading spinner, but the tweet never posts. I then click on the Twitter logo to "reload" the page, and I am met with Firefox's (well, in this case, Prism's) "Connection Interrupted" error:

Connection Interrupted
The document contains no data.
The network link was interrupted while negotiating a connection. Please try again.
[Try Again]

Clicking the "Try Again" button brings Twitter back up, as if nothing ever happened. And this all can happen within seconds, so Twitter doesn't necessarily have to be "down" at the time. And this has been the same sequence of events (whenever it happens) since Twitter actually did go down last month. (That is, it doesn't happen all the time, but when it does, it happens the same way every time.)
Comment 35 Mike Shaver (:shaver -- probably not reading bugmail closely) 2009-10-30 09:43:15 PDT
I haven't seen this in ages, and was seeing it all the time before.  Reports from other anecdotal folks have seemed to agree, and so I think that the pervasive, Firefox-only issue here (whatever it was) has gone away.  Getting ECONNRESET from a service under high load isn't unusual -- I propose that we WFM this, but also that it not block 1.9.2!
Comment 36 Gordon P. Hemsley [:GPHemsley] 2011-12-22 10:57:00 PST
There hasn't been any new information about this issue since 2009, and all the factors that influenced it have likely changed. As such, and per comment 35, resolving this WFM.

On the offchance that this issue comes up again, it'd probably be better to file a new bug, rather than reopening this one.

Note You need to log in before you can comment on or make changes to this bug.