Created attachment 623579 [details]
Security Tab for page info that shows in all Firefox versions
I used web version of tweetdeck as my twitter client and recently the tweet posting stopped working. So I tested it in all the channels and it only works in FF12, but all channels have the same security warnings so not sure what's wrong.
1. Go to https://web.tweetdeck.com/web/# and log on
2. Compose a tweet and hit "Tweet" button
3. On FF 13, 14, and 15, the spinner just spins for a couple of minutes and then seems to time out and the tweet dialog stays open
on FF 12, tweet shows up almost instantly in my timeline on tweetdeck. I also checked twitter and it's in my stream there.
Any help would be great since I love using this as my Twitter client.
A regression range could help.
I'm having an issue in my extension (TweeQuilla) where in Moz14 tweet posting is not working. The issue seems to be that when doing a POST xhr, onreadystatechange is only firing with readystate of 1, and not 2-4 (and 4 is the one that is important). A workaround for my extension is to use a "load" event listener instead.
Yet if this issue is broader than just my extension, then this is a serious regression. I mention it here as something specific that could be causing this current bug.
Created attachment 624151 [details]
nsHttp log for a failed request (using aurora Moz14 tb debug build)
This log shows what a failed tweet looks like. Eventually the request times out.
Created attachment 624152 [details]
nsHttp log for a good request (using release TB Moz12 debug build)
This shows what a successful status update log looks like.
The regression range is: 2012-02-08 works, 2012-02-09 fails. On further investigation the issue is bug 724563, which sets the preference:
I can also confirm that on the 2012-02-09 build the twitter status post works if I reset that preference to the original value (false).
Now nobody is going to give a hoot about my little extension that causes this to fail, but if FF is going to have serious issues in FF 13 with xhr POST messages than a lot of people are going to get concerned.
Jennifer, perhaps you could confirm that setting network.http.spdy.enabled to false fixes your issue.
I'm also adjusting the component to match that of the bug that I believe caused this regression.
Patrick, could you take a look please?
(In reply to Kent James (:rkent) from comment #5)
> Jennifer, perhaps you could confirm that setting network.http.spdy.enabled
> to false fixes your issue.
Yes that worked, but what side effects does turning that pref to false have?
tweetdeck started using spdy recently - not sure of the exact date.
I can confirm that I have problems even with the create account screen with spdy (though logging in is fine if I do have an account).
I'll look into figuring out the problem, seeing who is to blame, and figuring out what we can be done.
This is pretty easy to diagnose - tweetdeck uses PUT and POST with a content-length of 0.. I see the PUT when creating a new account, and the http log attached to this bug (thank you kent) shows the same thing with a POST. Nothing wrong with that, btw.
There are 2 equivalent ways to gateway a 0 len put/post into SPDY..
a] a SYN_STREAM that contains the method and other headers plus a fin bit in the flags
b] a SYN_STREAM that contains the method and headers but no fin bit and then a data frame of 0 length with a fin bit
Firefox uses [b], and that causes tweetdeck to hang and never send a response. If I change it to [a] tweetdeck works fine.
Unfortunately during original spdy development google servers had some trouble with [a] so I went with [b] instead. I don't know if that's cleared up or exactly how to confirm it (the problem was insconsistent). In either case it seems like it is better fixed on the server side. This is "Server: tfe" which iirc is internal proprietary twitter code.
I'll see if I can get someone on the twitter spdy team to take an interest.
(In reply to Jennifer Arguello :ticachica from comment #7)
> Yes that worked, but what side effects does turning that pref to false have?
it means you will always use http/1 instead of spdy/2 even when the server offers spdy/2 (e.g. google, twitter, ..).. and that can be a performance loss - but its equiv to ff12
Just to be clear, the extension that I have reported my issues with is not using Tweetdeck, but the Twitter api. See here for the code (with allowSpdy = false to fix for me):
(In reply to Kent James (:rkent) from comment #11)
> Just to be clear, the extension that I have reported my issues with is not
> using Tweetdeck, but the Twitter api. See here for the code (with allowSpdy
> = false to fix for me):
thanks kent - the http log you included in comment three shows this is the same issue I describe in comment 9. your extension is sending a 0 length post (with all the interesting stuff in the URI) and api.twitter.com does not respond when it is encoded in spdy as a 0 length dataframe with the fin bit.
I've sent some email to the twitter spdy folks I know. We'll see what they say.
Patrick - do we have any options on our side, or is this purely an evangelism bug?
(In reply to Alex Keybl [:akeybl] from comment #13)
> Patrick - do we have any options on our side, or is this purely an
> evangelism bug?
I know the timing is tight - but I'd favor giving evang a little bit of time. I just heard back from someone at twitter and they're assessing it on their side now.
if we run out of runway on that front front we can either pref off spdy (boo!) or add a twitter blacklist for it (hardcoded into just ff13) with very little notice. we could also easily change to option [b] from comment 9 (it just involved deleting 3 lines of code), but I don't feel confident that we could meaningfully validate interop with other spdy deployments in the allotted time.
Impressively, the twitter team has identified and fixed this in netty the same day it was sent to them.. hopefully it can be pushed it to twitter prodution soon.
Let's do as you describe in Comment 14 by 5/28 if the Twitter team doesn't expect to roll that out to production prior to 6/5.
I can confirm twitter has pushed a fix into production that fixes receives of data len=0 with the fin bit. Thanks @jpinner!
I'd appreciate confirmatsions from Kent and Jennifer too, if possible.
Just flipped network.http.spdy.enabled back to "true". Restarted Nightly-15.0a1 (2012-05-16) and posted a tweet. It worked! Yeah! Thanks everyone for such a quick turn around.
My extension also now works with spdy on (as it is by default) in Thunderbird Beta (Moz13).