Closed
Bug 510985
Opened 15 years ago
Closed 12 years ago
Twitter submission throbber spins endlessly
Categories
(Core :: General, defect, P2)
Core
General
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
Flags: blocking1.9.2+
Assignee | ||
Comment 1•15 years ago
|
||
A somewhat superficial finding: attempting to submit an update after modifying |twttr.form_authenticity_token| results in behavior identical to that reported.
Comment 2•15 years ago
|
||
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•15 years ago
|
||
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 ..?
Assignee | ||
Comment 4•15 years ago
|
||
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•15 years ago
|
||
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
Assignee | ||
Comment 6•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
Rey suggested I copy in jresig as Twitter is using jQuery ...
Comment 10•15 years ago
|
||
I've been looking at the headers both with LiveHTTPHeaders and the Charles proxy. Haven't seen anything strange yet.
Comment 11•15 years ago
|
||
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.
Assignee | ||
Comment 12•15 years ago
|
||
(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•15 years ago
|
||
(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
Assignee | ||
Comment 14•15 years ago
|
||
(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•15 years ago
|
||
(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?
Comment 17•15 years ago
|
||
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•15 years ago
|
||
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.
Assignee | ||
Comment 19•15 years ago
|
||
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•15 years ago
|
||
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. :-/
Comment 22•15 years ago
|
||
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•15 years ago
|
||
(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•15 years ago
|
||
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•15 years ago
|
||
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?
Assignee | ||
Comment 26•15 years ago
|
||
(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•15 years ago
|
||
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?
Assignee | ||
Comment 28•15 years ago
|
||
(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•15 years ago
|
||
Has this gone away? Is this FIXED? Are people still hitting it?
Comment 30•15 years ago
|
||
I haven't seen any failures to post, but I am still seeing occasional connection resets.
Comment 31•15 years ago
|
||
I've not hit it again since posting above, and I was getting caught by it frequently before.
Comment 32•15 years ago
|
||
This seems to be rearing its ugly head again....
Comment 33•15 years ago
|
||
Gordon, do you more details?
Comment 34•15 years ago
|
||
(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.)
Updated•15 years ago
|
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!
status1.9.2:
--- → wontfix
Flags: blocking1.9.2+ → blocking1.9.2-
Comment 36•12 years ago
|
||
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.
Description
•