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
As part of this ticket, stop accepting “Tails - Trying a testing version of Tails” in the test suite: that was introduced in 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
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 #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 #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 80d971bbf27752747b0be99646a38d881f237ed8 (Aug 20)
- job 1811 at 931874d35999be7072eeab3f27f2bfd528f61412 (Aug 15)
Then I’ve looked at 6 consecutive jobs from Aug 10-12 (jobs 1801-1806, d9a8be5b683b38ceff7987bf71bd949ac37c34b0 to 051bb7c1b3090498058ba0924afe8bf0149b1f92) and could spot only one case when JS was disabled (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.
Attachments
Related issues
- Related to #16613 (closed)
- Related to #15777 (closed)
- Related to #15905 (closed)
- Related to #11592 (closed)
- Has duplicate #17053 (closed)
- Blocks #16209
Original created by @intrigeri on 17007 (Redmine)