Tweetdeck's Web interface can't post tweets in TBB on Linux

Tweetdeck's Web interface (https://web.tweetdeck.com) doesn't work on the Tor Browser Bundle (Error: unable to initialize UI.) This is most likely due to the fact that there is no local storage in TBB. I've notified a Tweetdeck developer and he said they'll fix it soon. Will update when it is fixed.

added component::applications/tor browser owner::erinn parent::8401 priority::medium resolution::worksforme status::closed tbb-rebase-regression tbb-usability-website type::defect labels

Trac:
Owner: N/A to mikeperry
Component: - Select a component to TorBrowserButton

Can you try the TBB alphas? They support DOM storage safely (no disk access, and isolated to first party domain): https://blog.torproject.org/blog/new-firefox-17-and-tor-alpha-bundles

Be aware that it is an alpha, and more auditing work needs to be done on Firefox 17 in general, though.

Trac:
Keywords: N/A deleted, tbb-usability-website added
Type: project to defect
Component: TorBrowserButton to Firefox Patch Issues

Update: It works on the TBB alpha version. I am able to see the login box and the error mentioned earlier does not appear.

Things that work:

1. I am able to login and read tweets.

Things that don't work:

1. Some of the buttons/icons, namely the "reply", "retweet", "favorite" and "additional actions" do not display properly (instead of the icon, there is a rectangle with some numbers inside.)
2. I was unable to post a tweet. When I tried typing something and clicked "Tweet", it just showed me the loading symbol and nothing happened. I had to reload the page to exit this box.

Trac:
Cc: N/A to g.koppen@jondos.de

The icon and tweet posting thing is weird. Are we sure that's not an HTTPS-Everywhere issue? If you don't mind risking sending stuff unencrypted, perhaps you might try clicking on HTTPS-Everywhere icon (the blue pointy one) and clicking Disiable and testing temporarily? Maybe you want to create a throwaway account for testing that, though...

I tried it after disabling HTTPS-Everywhere but the problem still exists; unable to post and weird icons.

I noticed that NoScript in TBB alpha detects a blocked object: , video/ogg@https://web.tweetdeck.com/web/assets/sounds/tweet.9663ad9dcb.ogg

Enabling this object doesn't solve the problem, though.

I tried this on (the latest stable) Firefox 18.0.2 and:

1. The icon problem still persists, but

2. I am able to post tweets

Thanks for looking into this in more detail. Here's some more guesses:

1. I suppose it could also be NoScript being aggressive and trying to stop a false-positive XSS issue or something.. I assume you've checked the Tools->Web Developer->Error Console for messages?

2. It could be related to disabling 3rd party cookies in Tor Browser. You can try re-enabling them under the browser's main Preferences->Privacy->Accept third-party cookies. You can also try disabling them in your normal Firefox for a controlled experiment datapoint.

3. The tweet posting failure thing could be some IP-based rate limiting on tweetdeck's side that makes it hate Tor?

Trac:
Summary: Tweetdeck's Web interface doesn't work on TBB to Tweetdeck's Web interface can't post tweets in TBB

1. I monitored the Error Console and this is what it indicates:

1.1 Warnings

There are a bunch of warnings that look like this:

"Error in parsing value for 'background-image'. Declaration dropped. https://web.tweetdeck.com/web/css/app-dark.a83cc44d8f.css"

"Unknown property '-moz-border-radius'. Declaration dropped. https://web.tweetdeck.com/web/css/app-dark.a83cc44d8f.css"

and so on. The only difference is the "property" varies: moz-border-shadow, box-sizing etc. I guess this has something to do with the icons not displaying correctly.

1.2 Errors

When I click on the "Post tweet" button, there is one error that keeps repeating until I refresh the page.

"TypeError: c is undefined https://web.tweetdeck.com/web/scripts/default.c07bc4ddc5.js"

2. Enabling 3rd party cookies doesn't make a difference. The problem still persists. I always run my normal Firefox with 3rd party cookies disabled, and Tweetdeck web works fine (except for the icons, of course.)

3. I guess only someone who works for Tweetdeck will be able to answer this.

Note: I even disabled NoScript and tried to post a tweet, but it didn't work. I got the same error as indicated in Section 1.2.

Can you try setting the proxy settings in your Firefox browser to match your TBB (or system tor's) SOCKS proxy settings? If it works then, we can probably rule out 3 and at least be sure it is something in TBB.

You're also not running any additional addons like Ghostery. RequestPolicy, or Adblock in TBB, I assume? I am wondering about that 'c is undefined' error. It makes me think some javascript is missing/blocked/didn't load somehow. Does that same error show up in your normal Firefox's error console?

1. I'm not running any additional addons in TBB alpha other than the ones that are already installed.

2. I changed the network settings in normal Firefox to route traffic through Tor (socks 9050.) I'm able to login and post tweets using Tweetdeck web. The error console doesn't show the "c is undefined" error. It does show the same warning as from TBB, though (moz-border-radius etc.)

Hrmm. We're running out of things this could be. Torbutton in TBB-alpha is pretty stripped down, you disabled NoScript and HTTPS-Everywhere... That basically leaves either the patches or the pref changes. Here's some pref changes you can try (type about:config in your url bar).

Set this to true: browser.send_pings.

Set all these to false: security.ssl.enable_false_start, network.http.pipelining, network.http.pipelining.aggressive, network.http.pipelining.ssl, network.http.proxy.pipelining, browser.cache.memory.enable

If it works with all those changed, then try to narrow it down to the pref or prefs that actually matter.

Don't forget to change the prefs back when you're done (to avoid altering your TBB fingerprint).

Oh, and if it still doesn't work after changing all those prefs, try going back to TBB-stable and setting dom.storage.enabled to true in about:config. We patched our DOM storage implementation in TBB-alpha, but it is unpatched and merely disabled in TBB-stable. It could actually be that patch that is causing problems, I suppose.

Hi, sorry for the late reply.

1. After changing all those pref changes in about:config in TBB-alpha, it still doesn't work. I get the same "TypeError: c is undefined" error while trying to post tweets.

2. I went back to TBB-stable and set dom.storage.enabled to "true", and it worked. I was able to login and post tweets successfully. There was no "c is undefined error."

Looks like it is the DOM storage implementation that is causing problems.

Thanks! Adding the developers of that patch to assign/Cc.

mcs/brade - Do you think you could look into this at some point? I think the hours can be counted under your #6564 (closed) work. It might also make sense to change the error and logging of GetFirstPartyURI first as we discussed in email to help make diagnosing this easier? (Heads up: I am about to merge a minor fix to the image cache patch to maint-2.4 in the next day or two).

Trac:
Status: new to assigned
Cc: g.koppen@jondos.de to g.koppen@jondos.de, mcs, brade
Owner: mikeperry to brade
Parent: N/A to #6564 (closed)

Kathy (brade) and I took a quick look but were unable to reproduce the "Cannot tweet" problem with TBB 2.4.9 alpha 1 on Mac OS or Windows XP. I am not sure why tweeting works for us.

We do see the missing icons problem. The icons are rendered using custom Unicode characters and a custom font. Does TBB block use of custom fonts?

Hrmm.. Very strange. cypherpunks: Did you try this out from a totally fresh TBB directory?

Wrt fonts: We should have stopped blocking remote @font-face in TBB-alpha, but unfortunately our anti-fingerprinting font limiting patch (https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch) counts remote @font-face towards those limits, which usually means we run out of fonts and start blocking them. This is technically #5798 (moved), but we might want to break it out into a separate ticket.

I've banged on the font patch for several hours and was unable to find a route from the CSS evaluation rules to the actual source of the fonts (to determine if they were local or @font-face, to exempt the remote ones). The best idea I had was doing a QueryInterface on nsRuleNode::mFont to try to convert it to an nsIDOMCSSFontFaceRule and then exempt the ones that succeed that QI. Unfortunately, none of the @font-face fonts seem to actually succeed this QI. If either of you guys have any suggestions for other approaches I could try, I am willing to try coding them and testing them myself, since it's pretty important.. But I'm at a loss right now :/

Yes, it was a totally fresh TBB directory.

I just tested it again (package: tor-browser-gnu-linux-i686-2.4.9-alpha-1-dev-en-US.) I verified the package and made sure it has a good signature. The problem still exists: "TypeError: c is undefined" and unable to post tweets (loading symbol until I refresh the page)

My OS specifications are:

Debian 6.0.6 Squeeze

Kernel Linux 2.6.32-5-686

Gnome 2.30.2

2.0 GB RAM

Intel Core 2 Duo CPU 2.1 GHz

(Not sure if this might be useful, but this is the Vidalia log when I start TBB-alpha):

Feb 11 15:02:41.555 [Notice] Tor v0.2.4.9-alpha (git-23dd7c901287d7d8) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1c. Feb 11 15:02:41.555 [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Feb 11 15:02:41.555 [Notice] This version is not a stable Tor release. Expect more bugs than usual. Feb 11 15:02:41.555 [Notice] Read configuration file "/home/username/Downloads/tor-browser_en-US/App/../Data/Tor/torrc". Feb 11 15:02:41.556 [Notice] Opening Socks listener on 127.0.0.1:0 Feb 11 15:02:41.556 [Notice] Socks listener listening on port 57416. Feb 11 15:02:41.556 [Notice] Opening Control listener on 127.0.0.1:0 Feb 11 15:02:41.556 [Notice] Control listener listening on port 49782. Feb 11 15:02:41.556 [Notice] Parsing GEOIP IPv4 file ./Data/Tor/geoip. Feb 11 15:02:42.858 [Notice] Bootstrapped 5%: Connecting to directory server. Feb 11 15:02:42.974 [Notice] Bootstrapped 10%: Finishing handshake with directory server. Feb 11 15:02:43.350 [Notice] Bootstrapped 15%: Establishing an encrypted directory connection. Feb 11 15:02:43.706 [Notice] Bootstrapped 20%: Asking for networkstatus consensus. Feb 11 15:02:43.825 [Notice] Bootstrapped 25%: Loading networkstatus consensus. Feb 11 15:02:45.563 [Notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Feb 11 15:02:45.719 [Notice] Bootstrapped 40%: Loading authority key certs. Feb 11 15:02:46.086 [Notice] Bootstrapped 45%: Asking for relay descriptors. Feb 11 15:02:46.087 [Notice] I learned some more directory information, but not enough to build a circuit: We have only 0/3213 usable microdescriptors. Feb 11 15:02:49.862 [Notice] We now have enough directory information to build circuits. Feb 11 15:02:49.862 [Notice] Bootstrapped 80%: Connecting to the Tor network. Feb 11 15:02:49.863 [Notice] Bootstrapped 90%: Establishing a Tor circuit. Feb 11 15:02:51.752 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working. Feb 11 15:02:51.753 [Notice] Bootstrapped 100%: Done.

(FYI I posted some more notes about the font-face thing to https://trac.torproject.org/projects/tor/ticket/5798#comment:10).

Replying to cypherpunks:

I just tested it again (package: tor-browser-gnu-linux-i686-2.4.9-alpha-1-dev-en-US.) I verified the package and made sure it has a good signature. The problem still exists: "TypeError: c is undefined" and unable to post tweets (loading symbol until I refresh the page)

My OS specifications are:

Debian 6.0.6 Squeeze ...

Thanks for testing it again. I can reproduce the problem on Linux (I did not test there earlier). I am not yet sure why the behavior is different on Linux vs. the other platforms. Kathy (brade) and I will spend more time on this soon.

I forgot to mention that the first error that appears on the JS console is: TypeError: e.clientController.client is null https://web.tweetdeck.com/web/scripts/default.c07bc4ddc5.js I then see a continuous stream of the "TypeError: c is undefined" messages.

I think I have a solution to the font/icon issue in https://gitweb.torproject.org/mikeperry/torbrowser.git/blob/bug3944-intlfixes:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch. I didn't test it with tweetdeck yet, but if the problem really is @font-face fonts, this should fix it. It should be merged into origin/maint-2.4 and end up in the next TBB-alpha as well as the first TBB-stable with FF17.

Mark and I have tested many different builds on Linux. Some of the browsers we built exhibited the problem and some of them didn't. Removing all of the Tor patches from the TBB browser did not fix the TweetDeck problem. The difference between a build where tweeting works and where it doesn't seems to be due to differences in mozconfig settings.

The TBB build process uses the following options: --disable-optimize --enable-official-branding --enable-strip --disable-tests --disable-debug --disable-maintenance-service --disable-crashreporter

According to about:buildconfig, Mozilla's Official 17.0.2 ESR builds use: --enable-update-channel=esr --enable-update-packaging --enable-official-branding --enable-stdcxx-compat --enable-warnings-as-errors

The two builds also use different versions of gcc. Mark and I are not sure should own this problem. Unless there is a reason to keep the current mozconfig options, the simplest solution would be to try switching the TBB builds to more closely match the options Mozilla uses. In particular, removing --disable-optimize and/or --disable-debug may fix the problem.

Trac:
Cc: g.koppen@jondos.de, mcs, brade to g.koppen@jondos.de, mcs, brade, erinn

Thanks for looking into this. Interestingly, we ran into a separate bug such that the build process crashed without --disable-optimize. It seemed to be specific to Debian 6.0.6 x86, and it not happen with newer gcc's on Ubuntu. Perhaps that is why they use --enable-stdcxx-compat? I will kick off a fresh TBB-alpha build with similar options in my Debian VM right now and see if it will at least not crash out during build.

Trac:
Owner: brade to erinn
Component: Firefox Patch Issues to Tor bundles/installation

Replying to mikeperry:

Thanks for looking into this. Interestingly, we ran into a separate bug such that the build process crashed without --disable-optimize. It seemed to be specific to Debian 6.0.6 x86,

Just as a FYI: We had crash issues as well without --disable-optimize when we used Debian 6.0.6 to build JonDoBrowser (e.g. using Google+ crashed the browser reliably). Switching to Ubuntu solved this problem. Back then I tried to get as close as possible to Mozilla's default mozconfig options but that did not resolve the issue (--enable-stdcxx-compat did not help).

Trac:
Parent: #6564 (closed) to N/A

Going to tag this as a regression even though we made some progress on it in FF17, because we suspect the build flag changes as the cause. See also #8352 (moved), which is another issue due to our Debian build options.

Trac:
Keywords: N/A deleted, tbb-rebase-regression added
Summary: Tweetdeck's Web interface can't post tweets in TBB to Tweetdeck's Web interface can't post tweets in TBB on Linux

Trac:
Parent: N/A to #8401 (moved)

Trac:
Keywords: N/A deleted, needs-triage added

Trac:
Keywords: needs-triage deleted, N/A added
Component: Tor bundles/installation to Tor Browser

Posting tweets in tweetdeck works seems to work in Tor Browser 4.x. Please reopen and describe some details of your configuration if this still happens.

Trac:
Status: assigned to closed
Resolution: N/A to worksforme

closed

mentioned in issue #8352 (moved)

moved to tpo/applications/tor-browser#8156 (closed)