Project

General

Profile

Bug #17121

Feature #16356: Upgrade to Tor Browser 9.0 (based on Firefox 68)

Tor Browser 9 sometimes won't load new URLs

Added by intrigeri 5 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

50%

Feature Branch:
feature/17121-disable-quantum-bar
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Browser

Description

I've just reproduced manually the "typing a URL + pressing Enter seems to be ignored" bug, that I had initially spotted in the test suite (#17056), classified as a test suite bug, and that I workaround'ed yesterday, believing it was test suite fragility.

So I'm afraid this is an actual bug in Tails :/

I've started Tails built from the #16356 branch, started Tor Browser, clicked the "New tab" icon, typed a URL and pressing Enter does nothing.

Once this is fixed, we should revert the series of workarounds that were added to make the test suite pass despite this bug: 6f71531208bac5ab92a9dc83bb3d9c4af4b383d2, 68e35ff31517225aa7edb8af77c9526f08508949, d2f19c4593c5073d1664f6585862d4d31818fec8, 465900996ee0a74a57eb891ee553a3c4b79721ef.


Related issues

Related to Tails - Bug #17056: Make test suite robust with Tor Browser 9.0 Resolved
Related to Tails - Bug #17143: Re-enable Tor Browser's "Quantum bar" Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision dfeaa6e9 (diff)
Added by anonym 5 months ago

Test suite: revert recent hacks for the "I open ..." step.

It turns out these hacks (introduced for refs: #17056) worked around a
real bug, not a test suite issue, so we are gonna fix the real bug
instead (refs: #17121).

Revision 8c37cc5c (diff)
Added by anonym 5 months ago

Browsers: disable the Quantum Bar.

Disabling it seems prevent a nasty bug observed on primarily
Jenkins (but also elsewhere) where the URL bar doesn't respond to
Enter and the suggestions pop-up doesn't show up.

Modifying this pref only changes which tech is used under the hood for
displaying the URL bar [0] so nothing will be different from users.

[0] https://www.ghacks.net/2019/06/27/this-is-firefoxs-new-quantumbar-address-bar/

Refs: #17121

Revision 41dff809
Added by intrigeri 5 months ago

Merge branch 'feature/17121-disable-quantum-bar' into devel (Closes: #17121)

History

#1 Updated by segfault 5 months ago

#2 Updated by intrigeri 5 months ago

  • Description updated (diff)

#3 Updated by intrigeri 5 months ago

  • Related to Bug #17056: Make test suite robust with Tor Browser 9.0 added

#4 Updated by intrigeri 5 months ago

I looked at Tor Browser 9 bug reports (see the description of the parent ticket for links to Trac queries) and these are the only ones that might be vaguely related:

#5 Updated by intrigeri 5 months ago

  • Priority changed from Elevated to High

#6 Updated by sajolida 5 months ago

This one is really nasty!
To open an URL, I typed it in LibreOffice Writer and right-clicked on it to open the link :)

#7 Updated by anonym 5 months ago

I spent quite some time trying to reproduce this locally in a VM (and a few tries on bare metal) without success. Meanwhile on my local automated test setup (nested VM) I had reverted the recent "I open ..." step hacks (mentioned in the ticket description) and were looping a suitable scenario, and it managed about 50 runs times without reproducing it in.

I need more details about how to reproduce this. VM or bare metal? Locale? DVD vs USB? Additional software? Anything?!?!
@intrigeri
@sajolida

#8 Updated by sajolida 5 months ago

Mine was in VirtualBox with d2f19c4593.

I did 3 more tests today:

  • 1 time: starting without Administration Password and launching Tor
    Browser before Tor is ready: couldn't reproduce.
  • 2 times: starting with Administration Password and launching Tor
    Browser after Tor is ready: could reproduce.

I didn't test more combinations :)

Ah, and the 2 times I could reproduce it I also got a nasty "Tor Browser
can't update to the latest version." in the top-right corner, hanging
from the hamburger menu.

#9 Updated by intrigeri 5 months ago

Hi @anonym,

I need more details about how to reproduce this. VM or bare metal? Locale? DVD vs USB? Additional software? Anything?!?!

It's reproducible (several times) during (almost?) any test suite run on a slower isotester, e.g. lizard's, once the aforementioned workaround is removed.

#17056 might have relevant extra details.

#10 Updated by intrigeri 5 months ago

Hi @sajolida,

Ah, and the 2 times I could reproduce it I also got a nasty "Tor Browser can't update to the latest version." in the top-right corner, hanging from the hamburger menu.

If this is with an image that has Tor Browser 9.0a6, that's expected.
If this is with an image that has Tor Browser 9.0a7, that's a new bug, which I can't reproduce currently, but we did some changes in this area yesterday again, I need to retry with a fresh image.

#11 Updated by segfault 5 months ago

It might be relevant that Georg believes that he has seen this issue once or twice with early Tor Browser nightly versions: https://trac.torproject.org/projects/tor/ticket/31978#comment:3

#12 Updated by segfault 5 months ago

intrigeri wrote:

Ah, and the 2 times I could reproduce it I also got a nasty "Tor Browser can't update to the latest version." in the top-right corner, hanging from the hamburger menu.

If this is with an image that has Tor Browser 9.0a6, that's expected.
If this is with an image that has Tor Browser 9.0a7, that's a new bug, which I can't reproduce currently, but we did some changes in this area yesterday again, I need to retry with a fresh image.

sajolida wrote that he used an image built from d2f19c4593, which does not have Tor Browser 9.0a7.

#13 Updated by anonym 5 months ago

intrigeri wrote:

Hi @anonym,

I need more details about how to reproduce this. VM or bare metal? Locale? DVD vs USB? Additional software? Anything?!?!

It's reproducible (several times) during (almost?) any test suite run on a slower isotester, e.g. lizard's, once the aforementioned workaround is removed.

Indeed, but that will make investigating this extremely costly. My hope was to get a machine in this state that I can investigate directly.

It's clear we won't find a fix before ~rc1, so I propose we mention this as a known issue and that we'd like to hear from users if they experience it so we can get an idea how common it is and possibly get some clues that will push us in the right direction.

#14 Updated by intrigeri 5 months ago

It's clear we won't find a fix before ~rc1, so I propose we mention this as a known issue and that we'd like to hear from users if they experience it so we can get an idea how common it is and possibly get some clues that will push us in the right direction.

I agree that if this problem is not fixed in time for ~rc1, we should document it as a known issue.

Regarding "how common it is": this could be useful indeed, even though the data we already have suggests to me that it's too common to be OK.

Regarding "get some clues": to get that, I think we'll need to ask affected users specific questions/data. At this point, I have no idea which ones. But perhaps your investigations or intuition will yield some ideas :)

#15 Updated by anonym 5 months ago

So I got access to an isotester, and reproduced the issue there and have been investigating it live.

First I noticed that the bug does more than prevent ENTER from visiting the site: in fact, we don't get the popup with suggestions like "Search for blah on DuckDuckGo", bookmarks, etc. So it's clearly not about lost key presses vs Sikuli or similar.

Second, in the JacaScript Console the following error seems to only occur when the bug triggers, which seems key to figure this one out:

No matching message handler for the given recipient. 4 MessageChannel.jsm:964

Currently tracing what this is about in the Tor Browser source code.

#16 Updated by anonym 5 months ago

anonym wrote:

Second, in the JacaScript Console the following error seems to only occur when the bug triggers, which seems key to figure this one out:
[...]
Currently tracing what this is about in the Tor Browser source code.

I've seen the bug reproduce without this error, so I'm abandoning this false lead.

#17 Updated by anonym 5 months ago

I can repair the URL bar by going Menu → Customize and then just clicking Done. At the same time this is logged in the js console, which could be related:

Leaking UrlbarInput._copyCutController! You should have called removeCopyCutController! UrlbarInput.jsm:240
    uninit resource:///modules/UrlbarInput.jsm:240
    _reset chrome://browser/content/browser.js:394
    customizeEnd chrome://browser/content/browser.js:369
    _customizationEnding chrome://browser/content/browser-customization.js:71
    handleEvent chrome://browser/content/browser-customization.js:21
    _dispatchToolboxEventToWindow resource:///modules/CustomizableUI.jsm:2540
    dispatchToolboxEvent resource:///modules/CustomizableUI.jsm:2545
    dispatchToolboxEvent resource:///modules/CustomizableUI.jsm:4285
    exit resource:///modules/CustomizeMode.jsm:502
    InterpretGeneratorResume self-hosted:1284
    AsyncFunctionNext self-hosted:839

#18 Updated by anonym 5 months ago

I have found a workaround: we need to set the pref browser.urlbar.quantumbar to false. This only changes which tech is used under the hood for displaying the URL bar (source) so I think this is safe as a workaround. At some point we'll have to undo it, though, since Firefox will obsolete the old tech in favor of the "Quantum bar", so the real problem has to be fixed in Firefox, whatever it is (the quantum bar failing to load on systems under stress?).

I'll prepare a branch.

#19 Updated by intrigeri 5 months ago

I have found a workaround: we need to set the pref browser.urlbar.quantumbar to false. This only changes which tech is used under the hood for displaying the URL bar (source) so I think this is safe as a workaround.

I'll prepare a branch.

Woohoooo! :)

At some point we'll have to undo it, though, since Firefox will obsolete the old tech in favor of the "Quantum bar", so the real problem has to be fixed in Firefox, whatever it is (the quantum bar failing to load on systems under stress?).

OK, while reviewing & merging your branch, I'll track this somewhere (ideally some place closer to upstream than our own Redmine).

#20 Updated by anonym 5 months ago

  • Status changed from Confirmed to In Progress

#21 Updated by intrigeri 5 months ago

  • Assignee set to anonym

#22 Updated by anonym 5 months ago

  • Status changed from In Progress to Needs Validation
  • % Done changed from 0 to 50
  • Feature Branch set to feature/17121-disable-quantum-bar

So I undid the "I open ..." hacks and put my workaround in place. Let's see what Jenkins thinks!

#23 Updated by anonym 5 months ago

  • Assignee changed from anonym to intrigeri

#24 Updated by intrigeri 5 months ago

So I undid the "I open ..." hacks and put my workaround in place. Let's see what Jenkins thinks!

Great. Code review passes.

I've also started build+test CI jobs on my slowest local Jenkins slave, where the issue occasionally happens.

So hopefully I'll be able to merge this late tonight or first thing tomorrow morning, before I start the release process for 4.0~rc1!

#26 Updated by intrigeri 5 months ago

  • Status changed from Needs Validation to Resolved
  • % Done changed from 50 to 100

#27 Updated by intrigeri 5 months ago

  • Assignee deleted (intrigeri)
  • % Done changed from 100 to 50

#28 Updated by intrigeri 5 months ago

  • Related to Bug #17143: Re-enable Tor Browser's "Quantum bar" added

Also available in: Atom PDF