Bug #17121
Tor Browser 9 sometimes won't load new URLs
50%
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 (Bug #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 Feature #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: commit:6f71531208bac5ab92a9dc83bb3d9c4af4b383d2, commit:68e35ff31517225aa7edb8af77c9526f08508949, commit:d2f19c4593c5073d1664f6585862d4d31818fec8, commit:465900996ee0a74a57eb891ee553a3c4b79721ef.
Subtasks
Related issues
Related to Tails - |
Resolved | ||
Related to Tails - |
Resolved | ||
Blocks Tails - Feature #16209: Core work: Foundations Team | Confirmed |
History
#1 Updated by segfault 2019-10-04 09:21:28
- blocks Feature #16209: Core work: Foundations Team added
#2 Updated by intrigeri 2019-10-05 07:51:15
- Description updated
#3 Updated by intrigeri 2019-10-05 07:51:37
- related to
Bug #17056: Make test suite robust with Tor Browser 9.0 added
#4 Updated by intrigeri 2019-10-06 04:48:12
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 2019-10-06 06:38:55
- Priority changed from Elevated to High
#6 Updated by sajolida 2019-10-07 21:11:22
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 2019-10-08 13:49:41
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 2019-10-08 16:02:50
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 2019-10-09 07:19:28
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.
#10 Updated by intrigeri 2019-10-09 07:21:13
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 2019-10-09 07:26:11
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 2019-10-09 07:28:32
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 2019-10-09 08:33:03
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 2019-10-09 09:35:33
> 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 2019-10-09 12:17:37
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 2019-10-09 12:38:01
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 2019-10-09 12:52:17
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 2019-10-09 13:28:11
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 2019-10-09 13:37:43
> 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 2019-10-09 13:39:44
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|dfeaa6e96e767dcd96304cceeb5aaa39ef2b4469.
#21 Updated by intrigeri 2019-10-09 13:40:14
- Assignee set to anonym
#22 Updated by anonym 2019-10-09 13:40:36
- 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 2019-10-09 13:44:43
- Assignee changed from anonym to intrigeri
#24 Updated by intrigeri 2019-10-09 14:53:17
> 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!
#25 Updated by intrigeri 2019-10-09 16:51:03
FWIW, https://trac.torproject.org/projects/tor/ticket/32019 seems very similar.
#26 Updated by intrigeri 2019-10-09 19:35:15
- Status changed from Needs Validation to Resolved
- % Done changed from 50 to 100
Applied in changeset commit:tails|41dff809144e3ad519e58a25969554d7845e990e.
#27 Updated by intrigeri 2019-10-09 19:36:10
- Assignee deleted (
intrigeri) - % Done changed from 100 to 50
#28 Updated by intrigeri 2019-10-09 19:39:01
- related to
Bug #17143: Re-enable Tor Browser's "Quantum bar" added