TB9: Address bar and hotkey broken

1. Extract a fresh TB9 (I tested it with 9.0a7 and the 2019-10-08 nightly on Fedora Linux 30).

2. Before the first start, set about:blank as the homepage: {{{ export TOR_DEFAULT_HOMEPAGE=about:blank

   alternatively:

   echo 'user_pref("browser.startup.homepage", "about:blank");' >>Browser/TorBrowser/Data/Browser/profile.default/prefs.js }}}

3. Run ./start-tor-browser.desktop, connect to Tor, and wait until the main browser window opens.

After typing an URL into the address bar, it cannot be confirmed with Enter. (And autocomplete doesn't work either, e.g. "blog" is not completed to "blog.torproject.org/".) This seems to only affect the first start of a fresh TB9 installation.

If Ctrl+Shift+u (the hotkey for New Identity) is pressed while the address bar has focus, an underlined u is typed in. This problem remains even after a restart.

In contrast to #27427 (moved), the bug appears unrelated to NoScript - deleting the NoScript .xpi makes no difference. Workaround: data:, instead of about:blank as the homepage URL.

Trac:
Username: rustybird

added AffectsTails GeorgKoppen201911 TorBrowserTeam201911 actualpoints::0.1 component::applications/tor browser ff68-esr owner::tbb-team points::1 priority::medium reporter::rustybird resolution::fixed severity::normal status::closed tbb-9.0-issues tbb-9.0.1-can tbb-regression type::defect labels

intrigeri, segfault: I wonder whether that's one of your Tails bugs (where the URL bar is not responsive).

Trac:
Cc: tbb-team to intrigeri, segfault

Interesting that you bring up Tails: IIRC they don't set about:blank, but they do use a setup that's more or less equivalent to TOR_SKIP_LAUNCH=1 - which for me (though I haven't tried it in complete isolation yet) seems to occasionally trigger the bug even with about:tor as the homepage.

Trac:
Username: rustybird

Indeed, we don't set the homepage to about:blank. But the symptoms look very much the same as what's been reported here.

Our CI is currently testing a workaround that anonym found: setting browser.urlbar.quantumbar to false.

The corresponding Tails ticket is https://redmine.tails.boum.org/code/issues/17121.

Trac:
Keywords: N/A deleted, AffectsTails added

Trac:
Points: N/A to 1
Keywords: N/A deleted, TorBrowserTeam201910, GeorgKoppen201910 added

Setting data:, as the homepage just now happened to still trigger the bug, so it really doesn't look like it's about:blank specific - just more likely in that case. (I don't think I'm allowed to edit the ticket title)

browser.urlbar.quantumbar=false has been working good so far.

Trac:
Username: rustybird

Replying to rustybird:

Setting data:, as the homepage just now happened to still trigger the bug, so it really doesn't look like it's about:blank specific - just more likely in that case. (I don't think I'm allowed to edit the ticket title)

browser.urlbar.quantumbar=false has been working good so far.

Does this bug happen reliably for you? Or am I right in my assumption that it is happening sometimes/often but that we don't have steps to repro it 100%?

Trac:
Summary: TB9: Address bar and hotkey broken if homepage is about:blank to TB9: Address bar and hotkey broken

Replying to gk:

Does this bug happen reliably for you? Or am I right in my assumption that it is happening sometimes/often but that we don't have steps to repro it 100%?

FWIW, in Tails' context it happens very reliably on slower systems, and very rarely (or never at all) on faster ones. Sounds like a race condition to me.

Replying to gk:

Does this bug happen reliably for you?

With about:tor, data:, or a file:// homepage (the latter is the default on Whonix Workstation), it only happens sometimes. TOR_SKIP_LAUNCH=1 seems to increase the chance. OTOH about:blank has triggered it 100% of the times I went through the steps in the ticket description.

Replying to intrigeri:

FWIW, in Tails' context it happens very reliably on slower systems, and very rarely (or never at all) on faster ones. Sounds like a race condition to me.

Yeah, my system is also rather slow...

Trac:
Username: rustybird

Trac:
Keywords: N/A deleted, tbb-9.0-issues, tbb-regression, tbb-9.0.1-can added

FWIW and to give an update: I've a machine where I can reproduce the problem. Surprisingly, I have still trouble convincing the installed Firefox to show the bug. So, I am in the process of kind of bisecting the problem on our side first to have better steps to repro (as I assume this is actually a Firefox bug).

rustybird: Could you try the latest alpha and see whether you can reproduce the bug? I can see the problem in 9.0a7 but not in 9.0a8 (and thus 9.0) anymore.

Trac:
Status: new to needs_information

Replying to gk:

Could you try the latest alpha and see whether you can reproduce the bug? I can see the problem in 9.0a7 but not in 9.0a8 (and thus 9.0) anymore.

Indeed, I tried 9.0-build2 [edit: and 9.0a8] with and without TOR_DEFAULT_HOMEPAGE=about:blank and/or TOR_SKIP_LAUNCH=1 a couple of times and the main bug seems to be gone. Hurray?

One thing that might be relevant somehow: The minor secondary aspect of this ticket - If Ctrl+Shift+u (the hotkey for New Identity) is pressed while the address bar has focus, an underlined u is typed in. - now reliably occurs every time in every configuration here. I don't remember that being the case for 9.0a7, but maybe my memory is wrong. (Is there an archive where old alpha versions can still be downloaded? I don't have a copy of 9.0a7 anymore.)

Trac:
Username: rustybird

Replying to rustybird:

Replying to gk:

Could you try the latest alpha and see whether you can reproduce the bug? I can see the problem in 9.0a7 but not in 9.0a8 (and thus 9.0) anymore.

Indeed, I tried 9.0-build2 with and without TOR_DEFAULT_HOMEPAGE=about:blank and/or TOR_SKIP_LAUNCH=1 a couple of times and the main bug seems to be gone. Hurray?

One thing that might be relevant somehow: The minor secondary aspect of this ticket - If Ctrl+Shift+u (the hotkey for New Identity) is pressed while the address bar has focus, an underlined u is typed in. - now reliably occurs every time in every configuration here. I don't remember that being the case for 9.0a7, but maybe my memory is wrong. (Is there an archive where old alpha versions can still be downloaded? I don't have a copy of 9.0a7 anymore.)

Good to hear. The archive is here: https://archive.torproject.org/tor-package-archive/torbrowser/.

I'll keep this ticket open to track down what actually fixed the problem...

Replying to gk:

The archive is here: https://archive.torproject.org/[...]

lol, I should have guessed that... thanks. Turns out the Ctrl+Shift+U = u behavior was already present in 9.0a7 in all configurations, so it's independent: #32189 (moved)

Trac:
Username: rustybird

Moving my tickets.

Trac:
Keywords: GeorgKoppen201910 deleted, GeorgKoppen201911 added

Moving tickets to November 2019

Trac:
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201911 added

I've no time to investigate this. :( Thus, closing seems to be the "right" thing to do. If someone wants to dig a bit to understand what fixed the issue that would be appreciated.

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

Trac:
Actualpoints: N/A to 0.1

closed

changed time estimate to 8h

added 48m of time spent

mentioned in issue #32189 (moved)

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

mentioned in issue tpo/applications/tor-browser#32189 (closed)