Unable to open Google specific links in TBB

Similar to #6191 (closed) I'm unable to create a google docs spreadsheet.

Steps to reproduce:

1. login
2. click on "create"
3. select "spreadsheet" in the drop down menu that appears
4. a new tab opens (white page no content)

added component::firefox patch issues owner::mikeperry priority::medium resolution::fixed status::closed tbb-usability-website type::defect version::tor 0.2.3.20-rc labels

Changed the component to 'Firefox Patch Issues' (like in #6191 (closed)).

I'm using tor-browser-gnu-linux-x86_64-2.3.20-alpha-1-dev-en-US.tar.gz

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

Trac:
Keywords: N/A deleted, tbb-usability added

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

This is unlikely to get very much attention, unfortunately. One thing that will certainly make it go quicker is if someone can narrow down what is causing this on our side.

Does turning off any of the Torbutton privacy preferences stop it from happening?

Does it still happen with Torbutton in a Vanilla Firefox?

Is it because we set one of these prefs, by any chance: https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/prefs.js

Trac:
Keywords: tbb-usability deleted, tbb-usability-website added

The issue seems to be present for all Google specific links; creating any type of Google Docs document, opening any Gmail specific link, and so on.

Trac:
Summary: unable to create a google docs spreadsheet document with TBB to Unable to open Google specific links in TBB

I can add that this also happens when you try to follow a link in an email; clicking on a link that says https://www.torproject.org/ results in a new tab, blank page, and https://mail.google.com/mail/?shva=1 in the address bar.

Replying to mikeperry:

Does turning off any of the Torbutton privacy preferences stop it from happening?

Turning off "Isolate dynamic content to Tor state (crucial)" fixes the issue.

Thanks Runa! If that pref is the cause for all of the Google link failures, then simply removing that code should do the trick. There are other reasons to remove it, too (#5279 (closed)).

However, we'll probably going to want to ponder the side effects of that removal. I know it might change a bit about how New Identity works in terms of the tab tags (which are only defense in depth anyways), for example...

Replying to mikeperry:

Thanks Runa! If that pref is the cause for all of the Google link failures, then simply removing that code should do the trick. There are other reasons to remove it, too (#5279 (closed)).

Where in the codebase should I look?

However, we'll probably going to want to ponder the side effects of that removal. I know it might change a bit about how New Identity works in terms of the tab tags (which are only defense in depth anyways), for example...

Any suggestions on where to start to figure out how this will change New Identity and, possibly, other things?

Replying to runa:

Replying to mikeperry:

Thanks Runa! If that pref is the cause for all of the Google link failures, then simply removing that code should do the trick. There are other reasons to remove it, too (#5279 (closed)).

Where in the codebase should I look?

The observer for this is the nsIContentPolicy: https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/cssblocker.js

However, we'll probably going to want to ponder the side effects of that removal. I know it might change a bit about how New Identity works in terms of the tab tags (which are only defense in depth anyways), for example...

Any suggestions on where to start to figure out how this will change New Identity and, possibly, other things?

Unfortunately, the main reason I want to tear this old code out is because it's rather convoluted and full of voodoo from toggle mode. You can get some of the background in #1506 (closed) and the associated comments...

However, I think for the most part the content policy should be fairly isolated. I think the New Identity parts won't break without it, they'll just be setting some window tags they don't need to.

We have removed this code. This should be fixed. Reopen if not.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed

mentioned in issue #6944 (moved)