Opened 2 months ago

Closed 2 months ago

#27261 closed defect (duplicate)

Tor Browser 8.0a9/10 gets stuck in an endless reload cycle

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201808, ff60-esr, noscript
Cc: arthuredelstein, sysrqb, ma1, pospeselr, ezio Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We have report on our blog decscribing a scenario where Tor Browser 8.0a9/10 gets stuck in an endless reload cycle. The only remedy is to get rid of that copy and start over again. This happens "automatically" after a while. I saw this on one of my bundles on my Windows testing machine today as well. See: https://blog.torproject.org/comment/276402#comment-276402)

Child Tickets

Change History (20)

comment:1 Changed 2 months ago by gk

Cc: arthuredelstein added

Okay, so this is easy to reproduce: It happens both on win32 and win64 after the second restart or so. Just a clean 8.0a10 install. During the first session everything works as it should but later on just opening torproject.org (or probably any website) is enough to cause the endless loop. That seems locale independent as I tested with non-en-US and en-US bundles.

As far as I know it's only happening on Windows.

Arthur, can you look at this bug please?

comment:2 Changed 2 months ago by fixtbb

Isn't it a 'feature' of Tor Blog without js? During reloading:

Utils: Failed to serialize principal '[xpconnect wrapped nsIPrincipal]' [Exception... "Could not convert JavaScript argument arg 0 [nsISerializationHelper.serializeToString]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: resource://gre/modules/sessionstore/Utils.jsm :: serializePrincipal :: line 122"  data: no]

comment:3 Changed 2 months ago by kfseaperson

It also happens on Linux for me

comment:4 in reply to:  2 Changed 2 months ago by gk

Replying to fixtbb:

Isn't it a 'feature' of Tor Blog without js? During reloading:

Utils: Failed to serialize principal '[xpconnect wrapped nsIPrincipal]' [Exception... "Could not convert JavaScript argument arg 0 [nsISerializationHelper.serializeToString]"  nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)"  location: "JS frame :: resource://gre/modules/sessionstore/Utils.jsm :: serializePrincipal :: line 122"  data: no]

That's not about the blog but on any website.

comment:5 Changed 2 months ago by gk

Summary: Tor Browser 8.0a9/10 gets stuck in an endless reload cycle on WindowsTor Browser 8.0a9/10 gets stuck in an endless reload cycle

comment:6 Changed 2 months ago by gk

Cc: sysrqb added

Hm, I wonder whether sysrqb's comment over endlessly redownloaded images is related (see: comment:2:ticket:26561).

comment:7 Changed 2 months ago by gk

Cc: ma1 added
Keywords: noscript added

I looked a bit closer. The steps to reproduce are

1) Take a fresh Tor Browser 8.0a10
2) After opening go to torproject.org
3) Close the browser
4) Do steps 2) + 3) twice again
5) torproject.org and any other site are endlessly reloading.

I took a profile snapshot after step 3) and after step 5). Diffing them leads (among other things) to:

diff -r profile.default_first_start/compatibility.ini profile.default_issue/compatibility.ini
6d5
< InvalidateCaches=1

So, setting back InvalidateCaches=1 in compatibility.ini mitigates the issue. That's the first hint.

But the ultimate problem lies in NoScript. Disabling that extension makes the problem non-existent once it has been visible. As soon as I enabled NoScript again the endless redirecting shows up again.

Giorgio: could you please help with this bug? It's a release blocker for us and we have less than two weeks before we start building Tor Browser 8. Thanks!

Last edited 2 months ago by gk (previous) (diff)

comment:8 Changed 2 months ago by gk

Cc: pospeselr added

I wonder if that is a fallout from #26506 actually.

comment:9 Changed 2 months ago by ma1

Did you check whether this is actually reproducible with latest RC (10.1.8.17rc7)?

comment:10 Changed 2 months ago by gk

Yes, still the same issue.

comment:11 Changed 2 months ago by ma1

I've tried repeating the steps outlined in commment #7 not 3 but at least 30 times, with no results: the browser keeps behaving normally, unfortunately :(

Of course I did not even try 17rc7 (or rc8, which I've released some minutes ago), keeping 16 stable which ships with a fresh 8.0a10.

I'll keep testing on the RCs from now on, since 10.1.8.17 is about to be released and dramatically changes the way some possibly related subsystems work (hopefully reducing their side effects).

Here's my compatibility.ini file, in case it helps:

[Compatibility]
LastVersion=60.1.0_20180204020101/20180204020101
LastOSABI=WINNT_x86_64-gcc3
LastPlatformDir=C:\Users\Giorgio\Desktop\TB8\Browser
LastAppDir=C:\Users\Giorgio\Desktop\TB8\Browser\browser

comment:12 Changed 2 months ago by gk

Cc: ezio added

#27269 is a duplicate

comment:13 Changed 2 months ago by gk

https://www.dropbox.com/s/674t8y1o0s0vt8q/torbrowser.avi?dl=0 shows the problem (thanks ezio) and a potentially related one: once the reload cycle starts the extension menus don't open anymore.

The extension menus not opening anymore, however, is independent from NoScript. It happens as well with it removed from Tor Browser. So, my current theory is that there is an underlying bug that is causing to break NoScript (and the HTTPS-E and potentially other (Web)Extensions) in a way that the reload cycle happens.

comment:14 in reply to:  13 Changed 2 months ago by ma1

Replying to gk:

So, my current theory is that there is an underlying bug that is causing to break NoScript (and the HTTPS-E and potentially other (Web)Extensions) in a way that the reload cycle happens.

This is a pretty good working theory: in facts, one of the thing NoScript does to ensure other extensions don't interfere accidentally with the CSP it injects in webRequest.onHeadersReceived in the parent process, is checking whether scripts are actually blocked at a later stage (in the child process), and if they aren't, it triggers a page reload after trying its best to ensure NoScript has the final word on HTTP headers next time.

Therefore if something consistently messes with NoScript's ability to block scripts, and especially strips off the CSP headers of a page in a way that causes pages' JavaScript to bypass NoScript's restriction, that would likely cause a reload loop.

comment:15 in reply to:  13 ; Changed 2 months ago by fixtbb

Replying to gk:

https://www.dropbox.com/s/674t8y1o0s0vt8q/torbrowser.avi?dl=0

Blocked <media>: 1/1! But, hey, it's a clean 8.0a10! Do you initialize NoScript properly?

shows the problem (thanks ezio) and

Safest mode! Why didn't you mention it in your steps? SVG and downloadable fonts blocking is able to destroy content pages!

a potentially related one: once the reload cycle starts the extension menus don't open anymore.

or are not so fast to open.

The extension menus not opening anymore, however, is independent from NoScript. It happens as well with it removed from Tor Browser. So, my current theory is that there is an underlying bug that is causing to break NoScript (and the HTTPS-E and potentially other (Web)Extensions) in a way that the reload cycle happens.

Debugging is better with HTTPS-E disabled.

comment:16 in reply to:  11 Changed 2 months ago by ma1

Replying to ma1:

I'll keep testing on the RCs from now on, since 10.1.8.17 is about to be released and dramatically changes the way some possibly related subsystems work (hopefully reducing their side effects).

And doing so I suddenly realized I had to reopen ticked 26128, unfortunately, because the updateSettings message (like all the others exchanged internally by NoScript) is slightly changed in 10.1.8.17, prompting for a (quite simple) fix in order to keep the Security Slider working, sorry :(

comment:17 in reply to:  15 Changed 2 months ago by gk

Replying to fixtbb:

Replying to gk:

https://www.dropbox.com/s/674t8y1o0s0vt8q/torbrowser.avi?dl=0

Blocked <media>: 1/1! But, hey, it's a clean 8.0a10! Do you initialize NoScript properly?

shows the problem (thanks ezio) and

Safest mode! Why didn't you mention it in your steps? SVG and downloadable fonts blocking is able to destroy content pages!

That happens as well without touching the security slider at all.

comment:18 Changed 2 months ago by gk

While looking closer at this yesterday I made a first build to bisect this problem (assuming it is one of our patches that is the culprit here). It's been based on 7b0c76f7d2594ad8b016de4ae9748649c5e1836e and is still showing the same issue.

Arthur: I made a branch based essentially on 60.2.0esr (called 60.2.0esr-test in my repo) which reordered the commits for mingw-w64, moving them right to the start. Dunno if you want to try that one for bisecting as it should make it easier for Windows (modulo the other patches you still need from the tor-browser-build repo).

comment:19 in reply to:  18 Changed 2 months ago by hint

Replying to gk:
The Security Slider is now broken with NoScript 10.1.8.17 or you need to restart and remove startupCache for every change. *hint*

comment:20 Changed 2 months ago by gk

Resolution: duplicate
Status: newclosed

FWIW: Setting the security.sandbox.content.level level to 2 (which "solved" #26381) "fixes" this problem, too. As soon as I set it again to 3 and above the reload cycle is happening again. Duping this over to #26381.

Note: See TracTickets for help on using tickets.