Closed Bug 510985 Opened 15 years ago Closed 12 years ago

Twitter submission throbber spins endlessly

Categories

(Core :: General, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
status1.9.2 --- wontfix

People

(Reporter: mozilla+ben, Assigned: mozilla+ben)

Details

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
A somewhat superficial finding: attempting to submit an update after modifying |twttr.form_authenticity_token| results in behavior identical to that reported.
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 )
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 ..?
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.
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
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.
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?
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.
Rey suggested I copy in jresig as Twitter is using jQuery ...
I've been looking at the headers both with LiveHTTPHeaders and the Charles proxy. Haven't seen anything strange yet.
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.
(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?
(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
(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;
  }
(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.
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?
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?)
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.
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?
Saw this a few hours ago from Michael Arrington:
http://twitter.com/arrington/status/3412633383
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. :-/
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.
(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.
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.
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?
(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?!
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?
(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!
Has this gone away? Is this FIXED? Are people still hitting it?
I haven't seen any failures to post, but I am still seeing occasional connection resets.
I've not hit it again since posting above, and I was getting caught by it frequently before.
This seems to be rearing its ugly head again....
Gordon, do you more details?
(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.)
Priority: -- → P2
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!
Flags: blocking1.9.2+ → blocking1.9.2-
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.