754766 - Can't post tweets on web Tweetdeck in FF 15, 14, and 13

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Jennifer Arguello :ticachica]

Attachment: 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. 

STR:
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 
     OR
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.

Comment 1

[Matthias Versen [:Matti]]

A regression range could help.
- https://github.com/mozilla/mozregression

Comment 2

[Kent James (:rkent)]

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.

Comment 3

[Kent James (:rkent)]

Attachment: 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.

Comment 4

[Kent James (:rkent)]

Attachment: nsHttp log for a good request (using release TB Moz12 debug build)

This shows what a successful status update log looks like.

Comment 5

[Kent James (:rkent)]

The regression range is: 2012-02-08 works, 2012-02-09 fails. On further investigation the issue is bug 724563, which sets the preference:

pref("network.http.spdy.enabled", true);

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Patrick, could you take a look please?

Comment 7

[Jennifer Arguello :ticachica]

(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?

Comment 8

[Patrick McManus [:mcmanus]]

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.

Comment 9

[Patrick McManus [:mcmanus]]

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
or
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.

Comment 10

[Patrick McManus [:mcmanus]]

(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

Comment 11

[Kent James (:rkent)]

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):

https://bitbucket.org/rkentjames/tweequilla/src/ddd9e64b0187/modules/twitterHelper.jsm#cl-210

Comment 12

[Patrick McManus [:mcmanus]]

(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):
> 
> https://bitbucket.org/rkentjames/tweequilla/src/ddd9e64b0187/modules/
> twitterHelper.jsm#cl-210

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.

Comment 13

[Alex Keybl [:akeybl]]

Patrick - do we have any options on our side, or is this purely an evangelism bug?

Comment 14

[Patrick McManus [:mcmanus]]

(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.

Comment 15

[Patrick McManus [:mcmanus]]

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.

https://github.com/netty/netty/pull/330

Comment 16

[Alex Keybl [:akeybl]]

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.

Comment 17

[Patrick McManus [:mcmanus]]

I can confirm twitter has pushed a fix into production that fixes receives of data len=0 with the fin bit. Thanks @jpinner!

Comment 18

[Patrick McManus [:mcmanus]]

I'd appreciate confirmatsions from Kent and Jennifer too, if possible.

Comment 19

[Jennifer Arguello :ticachica]

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.

Comment 20

[[e-mail] (:bhearsum)]

WFM too.

Comment 21

[Kent James (:rkent)]

My extension also now works with spdy on (as it is by default) in Thunderbird Beta (Moz13).