Bug #17007

JavaScript sometimes blocked on Tor Browser first start ⇒ "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play

Added by intrigeri 2019-08-30 13:51:57 . Updated 2020-04-23 09:17:07 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

As part of this ticket, stop accepting “Tails - Trying a testing version of Tails” in the test suite: that was introduced in commit:b69a4dc6ab5094b4682ddf75f77d34d7fa51f330 (but keep the rest of the commit).

This scenario has failed 38 times, over the last 2 months, at the “I can watch a WebM video over HTTPs” step, so I’m going to mark it as fragile.

Interestingly, in the failure I’ve looked into, I see a NoScript click-to-play placeholder, while we’re supposed to let WebM play automatically these days.
I’ve seen another situation when JavaScript does not get executed: see commit:b69a4dc6ab5094b4682ddf75f77d34d7fa51f330, so I’m wondering if it might be that sometimes, Tor Browser gets configured with a higher security slider level than what we want. Hence setting priority >> normal, to investigate if that’s a bug in Tails or in our test suite.

As per Bug #11592#note-8 and following comments:

  • This bug affects Tails 3.x as well as Buster-based branches ⇒ not a regression in Buster.
  • This bug already occurred between Aug 7 and Aug 19, with Tor Browser 8.5.4 ⇒ not a regression in Tor Browser 8.5.5.

Nevertheless, as per Bug #17053#note-2, the first time sajolida saw this bug was a couple days ago, while running 4.0~beta2. Under the hypothesis that this bug is caused by a race condition, we can infer that:

  • Either something changed recently, that makes us lose this race condition more often in general.
  • Or something changed recently, that makes us lose this race condition more often with sajolida’s config and hardware.

On https://jenkins.tails.boum.org/view/RM/job/test_Tails_ISO_devel/ I’ve been annotating failed test suite runs with the reasons for failures. But I’ve been doing this only since August 31 so that’s not enough to bisect what “recently” means exactly here. One would need to analyze a bunch of test suite runs between Aug 9 (when we started running the full test suite on the devel branch) and Aug 31. I’ve sampled 6 jobs in this timespan and I’ve seen that JS was disabled in 2 of them:

  • job 1820 at commit:80d971bbf27752747b0be99646a38d881f237ed8 (Aug 20)
  • job 1811 at commit:931874d35999be7072eeab3f27f2bfd528f61412 (Aug 15)

Then I’ve looked at 6 consecutive jobs from Aug 10-12 (jobs 1801-1806, commit:d9a8be5b683b38ceff7987bf71bd949ac37c34b0 to commit:051bb7c1b3090498058ba0924afe8bf0149b1f92) and could spot only one case when JS was disabled (commit:0a1ea458111f16833e10cb02c4cd445990c32019).

For comparison, in the 20 runs since the beginning of September, I’ve attributed test failures to this bug 11 times. So yeah, it looks like the bug happens more often. Note, however, that Jenkins has been particularly busy in late Aug & early September, compared to the usual; workload variations can affect the occurrence rate of such race conditions.

Files

04_37_11_Watching_a_WebM_video.png (102018 B) intrigeri, 2019-08-30 13:48:58

Subtasks

Related issues

Related to Tails - Bug #16613: TorButton and/or NoScript are not fully set up on first Tor Browser launch: breaks circuits display and security slider Resolved
Related to Tails - Bug #15777: NoScript and HTTPS Everywhere icons are not shown on first start Resolved 2018-08-09
Related to Tails - Bug #15905: JavaScript disabled by default on recent builds from testing Resolved 2018-09-02
Related to Tails - Bug #11592: Step "[...] has loaded in the Tor Browser" is fragile Resolved 2016-07-22
Related to Tails - Bug #17462: Tor Browser in development builds sometime opens the wrong startup home page Confirmed
Has duplicate Tails - Bug #17053: JavaScript sometimes broken in Tor Browser 8.5.5 Duplicate
Has duplicate Tails - Bug #17684: Test suite failures: 4.6 vs. features/torified_browsing.feature Duplicate
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2019-08-30 19:52:53

  • Subject changed from "Watching a WebM video over HTTPS" test is fragile to "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile

Same for “Playing an Ogg audio track”: I often see a NoScript click-to-play placeholder.

#2 Updated by intrigeri 2019-08-30 19:53:37

  • Subject changed from "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile to "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play

#3 Updated by intrigeri 2019-08-31 05:57:56

#4 Updated by intrigeri 2019-09-04 08:07:36

  • Subject changed from "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play to JS sometimes blocked on Tor Browser first start ⇒ "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play
  • Category deleted (Test suite)
  • Target version set to Tails_3.17

I’ve just seen this while doing the 4.0~beta2 manual test suite: JS was blocked on first start. The security slider says “Standard” as expected. Nothing fishy in the logs. Restarting Tor Browser fixes the problem.

Let’s try to investigate a bit. Given our test suite sees this pretty often, it should be rather easy to collect whatever debugging info we need: let our test suite save it as build artifacts.

#5 Updated by intrigeri 2019-09-06 14:08:32

  • Subject changed from JS sometimes blocked on Tor Browser first start ⇒ "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play to JavaScript sometimes blocked on Tor Browser first start ⇒ "Watching a WebM video over HTTPS" and "Playing an Ogg audio track" scenarios are fragile: blocked by NoScript click-to-play

#6 Updated by intrigeri 2019-09-07 09:17:09

  • related to Bug #16613: TorButton and/or NoScript are not fully set up on first Tor Browser launch: breaks circuits display and security slider added

#7 Updated by intrigeri 2019-09-07 09:17:40

  • related to Bug #15777: NoScript and HTTPS Everywhere icons are not shown on first start added

#8 Updated by intrigeri 2019-09-07 09:20:39

To whoever will work on this, if you need to dive into the code, segfault wrote this elsewhere:

> Took me a while to find the code responsible for this, because I expected that it changes firefox preferences (i.e. the ones editable via about:config). But that doesn’t seem to be case - just FTR (maybe someone finds this when we have to check stuff like that again): NoScript is controlled via WebExtension messages, the code is in src/modules/noscript-control.js in torbutton.git.

#9 Updated by intrigeri 2019-09-07 10:33:27

  • related to Bug #15905: JavaScript disabled by default on recent builds from testing added

#10 Updated by intrigeri 2019-09-07 14:15:55

  • Description updated

#11 Updated by intrigeri 2019-09-12 14:25:43

  • Target version changed from Tails_3.17 to Tails_4.0

#12 Updated by intrigeri 2019-09-13 16:08:06

  • has duplicate Bug #17053: JavaScript sometimes broken in Tor Browser 8.5.5 added

#13 Updated by intrigeri 2019-09-14 05:40:59

  • Description updated

(Analyzed a bit occurrence rate on Jenkins.)

#14 Updated by intrigeri 2019-09-14 05:41:56

  • related to Bug #11592: Step "[...] has loaded in the Tor Browser" is fragile added

#15 Updated by intrigeri 2019-09-14 05:59:00

  • Assignee set to intrigeri

Next step: check if / how often this happens on the Tor Browser 9.0 branch (Feature #16356). I’ll do that once the test suite on that branch is robust enough to draw any such conclusion.

#16 Updated by intrigeri 2019-09-14 16:51:11

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|956da152d30c2ef1ff74578e1634090107367e01.

#17 Updated by intrigeri 2019-09-14 17:54:36

  • Status changed from In Progress to Confirmed

#18 Updated by intrigeri 2019-09-14 17:54:53

  • blocked by Bug #17056: Make test suite robust with Tor Browser 9.0 added

#19 Updated by intrigeri 2019-09-23 18:15:36

  • Assignee deleted (intrigeri)

I won’t be able to work on this before Saturday.

#20 Updated by segfault 2019-09-28 10:29:35

  • blocked by Bug #17100: devel branch FTBFS: linux-image-5.2.0-2-amd64 not available added

#21 Updated by segfault 2019-09-28 10:29:56

  • blocks deleted (Bug #17100: devel branch FTBFS: linux-image-5.2.0-2-amd64 not available)

#22 Updated by intrigeri 2019-10-03 09:25:01

  • Priority changed from Elevated to High
  • Target version deleted (Tails_4.0)

Unfortunately, Tor Browser 9.0 is affected too :/

I’ll remove the target version + bump priority for now as:

  • 3.x is affected too and I doubt we’ll find time to fix this in 4.0.
  • It’s a major bug and we should prioritize it as soon as we can.

#23 Updated by intrigeri 2019-10-03 09:25:55

  • blocks deleted (Bug #17056: Make test suite robust with Tor Browser 9.0)

#24 Updated by intrigeri 2019-10-03 17:38:05

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|dcbeaf52a6776fda0ca3000b9c9555a948001f00.

#25 Updated by intrigeri 2019-10-03 17:46:21

  • Status changed from In Progress to Confirmed

Not quite in progress :/

#26 Updated by intrigeri 2019-11-10 10:09:43

Hi emmapeel, goupille,
and @numbat!

Did you see this reported since 4.0~beta2 was released? How often?

#27 Updated by goupille 2020-01-07 16:55:13

  • Assignee set to intrigeri

as far as I know, it wasn’t reported on our helpdesk, but I saw that a few minutes ago with tails 4.1.1, I had to move the security cursor to “Safest”, then back to “Standard” to enable javascript

#28 Updated by intrigeri 2020-02-07 13:00:57

  • related to Bug #17462: Tor Browser in development builds sometime opens the wrong startup home page added

#29 Updated by intrigeri 2020-04-06 14:51:11

  • Assignee deleted (intrigeri)

#30 Updated by hefee 2020-04-07 17:20:06

We used this ticket within our first job interview together with @anonym we have follow thoughts to tackle this down:

  • maybe the startup between NoScript and Torbutton is not defined and the starting order is random. If the No-Script extensions starts later than Torbutton and the communication fails between Torbutton -> Noscript fails silently, than NoScripts may start with “higher security standard” and the test fails. No good idea how to debug this, except than look into the code of torbutton, if they handle the case, that the communication fails.
  • We have a workaround (switch to “Secure” back to “Standard”) - Does this fixes the issue everytime? A way to debug would be to store pref.js when the bug occurs, than do the workaround and look at the diff of the prefs.js. If prefs.js is not written, than we have to dump the current settings from about:config.
  • Maybe the prefs.js are correct, but NoScript loads the settings before they are written to file?

#31 Updated by segfault 2020-04-12 17:54:45

In the last 30 test runs of the stable branch and the last 30 test runs of the devel branch, these scenarios did not fail once with the described error (being blocked by NoScript click-to-play or anything else possibly related to Javascript being disabled).

I also started a 4.5 image 5 times in a row and didn’t see the issue once.

#32 Updated by intrigeri 2020-04-23 09:17:07

> Maybe the prefs.js are correct, but NoScript loads the settings before they are written to file?

We’ve seen aufs bugs in the past, that triggered similar problems. I would be curious if this problem ever happens in Tails 4.5+, that uses overlayfs instead of aufs. @goupille ?

#33 Updated by intrigeri 2020-05-07 09:00:53

  • has duplicate Bug #17684: Test suite failures: 4.6 vs. features/torified_browsing.feature added