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

intrigeri
2021-01-26T14:01:38Z

_Originally created by @intrigeri on [#17007 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/17007)_ As part of this ticket, once the bug is fixed, in the test suite, stop accepting: - "Tails - Trying a testing ver...

Originally created by @intrigeri on #17007 (Redmine)

As part of this ticket, once the bug is fixed, in the test suite, stop accepting:

"Tails - Trying a testing version of Tails": that was introduced in b69a4dc6 (but keep the rest of the commit)

"Tails - Welcome to Tails!": revert e5a61417

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 b69a4dc6, 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 #11592 (comment 58078) 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 #17053 (comment 2063), 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 80d971bb (Aug 20)

job 1811 at 931874d3 (Aug 15)

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

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.

Attachments

04_37_11_Watching_a_WebM_video.png

Related issues

Related to #16613 (closed)

Related to #15777 (closed)

Related to #15905 (closed)

Related to #11592 (closed)

Related to #17462

Has duplicate #17053 (closed)

Has duplicate #17684 (closed)