Liking sends a POST request to https://api.twitter.com/1.1/favorites/create.json with a parameter specifying the tweet id, and another int for the current number of likes. On 6.5 for me, this results in a response with status code "400 Bad Request". Digging into the JSON object sent in response, it has two fields:
As Isabela pointed out, retweeting still works, so I don't see how verification of the auth token is failing here. Perhaps they're trying to check auth cookies in some weird way?
If I set network.cookie.cookieBehavior to 0 (allow all cookies), the Like button works again. Just another data point: I also can't login to Tweetdeck. If I also set the var above to 0 login works. Don't know if both are related.
If I set network.cookie.cookieBehavior to 0 (allow all cookies), the Like button works again. Just another data point: I also can't login to Tweetdeck. If I also set the var above to 0 login works. Don't know if both are related.
The Tweetdeck issue is known as yawning pointed out with the hint to #16450 (moved). I suspect Twitter changed some things on their end that are now breaking the like button as well? Otherwise I would have expected folks complaining much earlier. 6.5 is around for almost five weeks now. Could someone with Twitter presence double-check that this is not a 6.5 regression by trying to hit the like buttons with 6.0.8? It still can be found under https://dist.torproject.org/torbrowser/. It would be helpful as well if anyone can check whether Firefox 52 with privacy.firstparty.isolate set to true is working. There are first pre-release builds available at: https://archive.mozilla.org/pub/firefox/tinderbox-builds/.
Trac: Keywords: N/Adeleted, tbb-usability-website added Status: new to needs_information
If I set network.cookie.cookieBehavior to 0 (allow all cookies), the Like button works again.
Thanks for reporting this -- I can confirm that. I examined the request headers for the POST observed by Isis in comment:1 under two different pref settings:
When network.cookie.cookieBehavior is 0, the header entry
Authorization: Bearer AAAAAAAAAAAAAAAAAAAAA[...]
is included (part of password is omitted in brackets)
When network.cookie.cookieBehavior is 1, that Auth header entry is missing, and the response includes message: "Bad Authentication data."
So the next step is to investigate why Firefox does this and also check if Firefox 52 has the same problem.
Turns out our patch from #13900 (moved) is too strict and disallows http auth headers from api.twitter.com under a twitter.com page. Here's a fixup for review:
Here are test builds with the patch applied. Can anybody hitting this issue in the wild confirm that those builds work while the currently released ones don't? Plus, while we are at it, can anybody test whether the tweetdeck login problem (aka #16540 (moved)) goes away with that patch as well?
Here are test builds with the patch applied. Can anybody hitting this issue in the wild confirm that those builds work while the currently released ones don't? Plus, while we are at it, can anybody test whether the tweetdeck login problem (aka #16540 (moved)) goes away with that patch as well?
I tested the 64-bit linux builds in a new fedora 24 VM, and had mostly good, but slightly mixed results. I logged into a twitter account for one of my bots, and randomly started liking and RTing things, and RTing always worked, liking almost always worked.
Liking occasionally failed, causing the like heart-emoji-thing to animate, and the number went up, but when checking the same tweet (logged into my personal account) in another Tor Browser, it showed the old number (i.e. before my bot account hit the like button). I vaguely suspect that this is because perhaps I had let the circuit expire, since I was multitasking, but I'm not entirely certain. I retested again, and liking always worked, so perhaps there was just some user-induced fluke there.
Overall, the behaviour is a significant improvement over the current stable behaviour.