Opened 5 weeks ago

Last modified 2 weeks ago

#26381 new defect

about:tor page does not load on first start in localized Windows bundle

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-torbutton, ff60-esr, TorBrowserTeam201807
Cc: mcs, brade, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When testing the Windows nightly builds I got greeted with an error page on first start

     <title>&aboutTor.title;</title>
------------^

This happened with a 32bit de bundle and I can't reproduce this on Linux. Moreover if I open about:tor in a new tab it works. From the second start on the about:tor page is shown as well.

Child Tickets

Change History (11)

comment:1 Changed 5 weeks ago by mcs

Kathy and I can reproduce this on Windows (32-bit de build) but not on macOS (de build).

It almost seems like an e10s problem, but I am not sure why it would be Windows-specific.

We also see both the Firefox "spoof language?" prompt as well as the Torbutton one. Is there already a ticket open for that issue?

comment:2 Changed 4 weeks ago by arthuredelstein

Cc: arthuredelstein added

comment:3 in reply to:  1 Changed 4 weeks ago by gk

Replying to mcs:

Kathy and I can reproduce this on Windows (32-bit de build) but not on macOS (de build).

It almost seems like an e10s problem, but I am not sure why it would be Windows-specific.

We also see both the Firefox "spoof language?" prompt as well as the Torbutton one. Is there already a ticket open for that issue?

Now we have: #26409.

comment:4 Changed 4 weeks ago by mcs

Kathy and I spent a little time looking at this today. I am recording our findings here in case someone else has any idea what might be going on. Here is what we know:

  1. The error is due to an undefined entity with aboutTor.xhtml.
  2. We only see the problem on Windows.
  3. This problem does not occur when multiprocess mode is disabled via set MOZ_FORCE_DISABLE_E10S=1.
  4. This problem does not occur when most of Tor Launcher is disabled during startup via set TOR_SKIP_LAUNCH=1.
  5. This problem does not occur when we allow Tor Launcher to do all of its work but suppress the windows that it normally opens (we had to modify the Tor Launcher code to make this possible).

This is all quite strange and leads Kathy and me to think that there is a general Firefox bug in loading of extension DTD files, e.g., maybe when e10s is enabled there is a race during startup which puts things in a bad state after Tor Launcher uses a DTD file during startup. Of course Tor Launcher should not be able to interfere with Torbutton in this way.

comment:5 Changed 4 weeks ago by gk

One observation I had today while testing a Windows sv-SE bundle: it seems that NoScript is somehow not properly working as well? At least adjusting the security slider does not seem to work and I can't click on the NoScript icon. However, that might be worth a different bug as I have this issue with an en-US bundle, too. But on my Linux box it is working as expected.

comment:6 in reply to:  5 Changed 3 weeks ago by arthuredelstein

Replying to gk:

One observation I had today while testing a Windows sv-SE bundle: it seems that NoScript is somehow not properly working as well? At least adjusting the security slider does not seem to work and I can't click on the NoScript icon. However, that might be worth a different bug as I have this issue with an en-US bundle, too. But on my Linux box it is working as expected.

I opened #26506 to look at this issue further.

comment:7 in reply to:  4 Changed 3 weeks ago by brade

Replying to mcs:

Kathy and I spent a little time looking at this today. I am recording our findings here in case someone else has any idea what might be going on. ...

Removing prefs.js allows you to reproduce this bug without installing a new browser.

comment:8 in reply to:  4 Changed 3 weeks ago by mcs

Replying to mcs:

  1. This problem does not occur when we allow Tor Launcher to do all of its work but suppress the windows that it normally opens (we had to modify the Tor Launcher code to make this possible).

For testing, here is a patch that implements the above (no windows opened by Tor Launcher):
https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug26381-test-01&id=698e6fe038d2c8b22efe569b6e2bdd77dd2327b9

comment:9 Changed 3 weeks ago by mcs

Tracking down the root cause of this is proving to be challenging. My Windows debugging skills seem to be inadequate, especially when the browser is running in multiprocess mode. Here are some additional things that Kathy and I learned:

  • In addition to the undefined entity bug, sometimes a blank page is loaded instead of about:tor. When a blank page is loaded, that tab is useless (all pages silently fail to load, including internal pages such as about:config).
  • The problems with about:tor do not always occur. They seem to occur every time with a clean install or when running with TOR_FORCE_NET_CONFIG=1.
  • When about:tor does not load correctly, Wextensions (all) do not work either. This points to some kind of race or other bug during initialization.
  • Reducing the sandbox level makes these problems disappear: if I set security.sandbox.content.level to 2 about:tor loads correctly every time, but a setting of 3 or higher causes problems.

comment:10 Changed 3 weeks ago by gk

The sandbox related part is interesting. I wonder whether we could create a minimum PoC for that, so that the issue is visible in a vanilla Firefox, too, and then we could go with that to Mozilla's bugzilla to get further help...

comment:11 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

Note: See TracTickets for help on using tickets.