nytimes.com login page loads after Torbutton toggled

In Firefox 4.0b9 with Torbutton 1.3.1-alpha installed and Tor enabled:

1. Open a new tab.
2. Enter [http://www.nytimes.com/2011/01/24/world/africa/24tunis.html] in the address bar and click the green arrow ('Go') button. The page will not load.
3. Close the tab.
4. Toggle Torbutton off.

A nytimes.com login page will appear, containing at least 24tunis in its URL.

added actualpoints::3 component::applications/torbutton owner::mikeperry points::10 priority::immediate resolution::fixed severity::normal status::closed type::defect version::torbutton 1.3.0-alpha labels

This page does in fact load for me.

How reliably can you reproduce this? It doesn't happen for me at all.

Trac:
Points: N/A to N/A

Replying to mikeperry:

This page does in fact load for me.

How reliably can you reproduce this? It doesn't happen for me at all.

The login page appeared every time I tried this in Firefox 4.0b9 before filing the bug report.

I have now tested this again several times:

1. In Firefox 4.0b9 on 'comet', I closed the tab while Firefox was displaying its gray 'Connecting...' animation, then toggled Torbutton. The login page did not appear.
2. Same procedure as 1; same result.
3. In Firefox 4.0b9 on 'comet', I closed the tab while Firefox was displaying its green 'Connecting...' animation, then toggled Torbutton. The login page appeared several minutes later in a new tab.
4. In Firefox 4.0b10 on 'ceres' (the computer on which I originally observed this bug), I closed the tab while Firefox was displaying its green 'Connecting...' animation, then toggled Torbutton. The login page appeared several minutes later in a new tab, in fact, several minutes after test 5.
5. In Firefox 4.0b10 on 'ceres', I accidentally toggled Torbutton before closing the tab, while Firefox was displaying its green 'Connecting...' animation; the login page loaded in the tab before I could close it.

'ceres' has the following Firefox extensions installed and enabled:

• Firebug 1.7X.0a9
• Greasemonkey 0.9.1
• HTTPS Everywhere (katmagic's tree branch) 0.9.9.tree.1 (as packaged by EFF)
• Java Console 6.0.23
• NoScript 2.0.9.6
• Torbutton 1.3.1-alpha

Both 'ceres' and 'comet' are running Windows 7.

Firefox is configured to reject cookies from wt.o.nytimes.com and www.nytimes.com on both 'ceres' and 'comet'.

Reproduce: 3 Fix: 7

Trac:
Points: N/A to 10

rransom: Since you have a semi-custom setup, and you can easily reproduce it, can you set torbutton's extensions.torbutton.loglevel to 2, and its logmethod to 0 and redirect Firefox's stdout for a few repro cases?

Since NYTImes doesn't always display a login page, can you try to also capture either that html, and/or use a request logger like Live HTTP Headers or Tamper Data to see exactly what requests are grabbed and when?

This doesn't seem to reproduce for me, so I'm at a loss. I'm guessing its some form of redirect timer that perhaps lives in a webthread that we don't effectively close after the toggle? Hence I need to see the source/request log for when nytimes does actually decide to even give you a login page.

On IRC, Mike Perry suggested that I try to reproduce this bug using Firefox 3.6, since the only debugging tool available for Firefox 4.0b9 (Firebug) didn't capture anything. I was able to reproduce the bug using Firefox 3.6.13 in a newly unpacked TBB for Windows 1.3.17 using the following procedure:

0. If possible, copy the cached-* files from a recently used Tor DataDirectory into 'Tor Browser/Data/Tor'.
1. Run 'Start Tor Browser.exe'.
2. When Firefox appears and has finished loading the 'Firefox Updated' and 'Are you using Tor?' pages, press Ctrl-T to open a new tab.
3. Click 'Tools', then 'Options...', then 'Privacy'; click 'Accept cookies from sites' to uncheck it. Click 'OK'.
4. Right-click on 'Tor Enabled' in the status bar, then click 'Preferences...'; click 'Disable Button and Hotkeys to prevent accidental toggle' to uncheck it. Click 'OK'.
5. Click 'View the Network' in the 'Vidalia Control Panel'.
6. Paste "http://www.nytimes.com/2011/01/24/world/africa/24tunis.html" into the Firefox address bar. Click on the right arrow to start loading the page.
7. After the progress bar in Firefox's status bar becomes about half-full, click 'Tor Enabled' to toggle Torbutton off. Firefox will continue to access subdomains of nytimes.com, but not through Tor. Eventually, a New York Times login page will appear.

Trac:
rransom-bug2428-http-header-dump-2011-02-03-01.txt.gz

HTTP requests during repro in TBB

I have attached a log (captured using 'Live HTTP Headers') of the HTTP requests that occurred while reproducing this bug in TBB for Windows 1.3.17. The 'Error Console' overflowed, and I don't think Firefox's stdout/stderr can be captured on Windows, so capturing Torbutton's log messages will require either modifying Torbutton or installing and using a capture-Firefox-log-messages-to-disk extension.

Hah. This is definitely a conflict with https-everywhere. It is possibly due to the synthetic channel replacement redirect that we do there that is allowing NYT to escape Torbutton's window stop events and content policy checks.

It looks like the tab's tor tag is being reset while a request is making it through HTTPS-Everywhere's redirect, because we are getting proper http observer notifications in torbutton, we just are not trying to block them.

We are not getting content policy notifications, however.. So it may be an issue with how we check these requests in our http observer.. We obtain the channel in that handler. It may be the wrong channel to cancel?

Trac:
https-everywhere-0.9.9.development.3_pre.xpi

HTTPS Everywhere with noscript update. Seems to fix the channel issue

rransom: Can you try this xpi to see if you still experience the issue? I could not get it to happen in my test setup that was reproducing the issue before I installed it.

Replying to mikeperry:

rransom: Can you try this xpi to see if you still experience the issue? I could not get it to happen in my test setup that was reproducing the issue before I installed it.

That XPI seems to have fixed this bug.

I just tested this again with HTTPS Everywhere 0.9.9.development.3 (as released 2011-02-06), and this bug is definitely fixed.

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

Trac:
Actualpoints: N/A to 3
Actualpointsdone: N/A to 3
Pointsdone: N/A to 10

Set all tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

closed

changed time estimate to 80h

added 24h of time spent

mentioned in issue #2490 (moved)

mentioned in issue #2513 (closed)

mentioned in issue tpo/applications/https-everywhere-eff#2490 (closed)