The test suite needs a stable <title> but ikiwiki uses [[!meta title]]
for both <title> and the page headline.

This commit overwrites <title> using JavaScript.

Using "Tails" as <title> is generic enough to make sense while
preventing to have to handle translations.

I see "Drive 'pRUZWkrmDo' is not detected by Tails (Timeout::Error)" too often
these days. In the debug log, I see "test -b /dev/sda" being called exactly once
and the surrounding try_for(20) timing out. I think that the remote shell gets
confused by update(domain_xml.to_s) which is called by plug_drive → plug_device,
e.g. the serial port it uses may be very temporarily unavailable and we're
unlucky enough that our remote shell client sends a request exactly at
that time. To support this hypothesis, after the failure, when one of our After
hooks runs this:

    if $vm && $vm.remote_shell_is_up?
      save_journal($config['TMPDIR'])
    end

… the remote shell client is confused, complains the ID of the answer it
receives is not the expected one, and the Journal is not saved
(which incidentally makes it hard to debug the very problem I'm trying to solve
here).

I've seen a few "Drive 'veracrypt' is not detected by Tails (Timeout::Error)".
Let's see if a bigger timeout helps.

With 10% I've seen "upload: write error: /veracrypt (Guestfs::Error)"
while with 15% we're good.

I broke it in commit 938a2d89 while adding
support for raw disks.

VeraCrypt test suite (USB drive): add pending scenarios and implement VeraCrypt volume creation (refs: #15238).

Test suite: adjust to the fact "New Circuit for this Site" is now in the site information and not under the Torbutton anymore (refs: #15803).

Use Tor Browser even for offline documentation, drop the custom documentation browser, and adjust the test suite accordingly (refs: #15720).

Incidentally, this brings back test suite robustness workarounds
that commit:74536c6a had removed,
which might help fix another bug (refs: #15321).

I've seen a false positive because journalctl was run too early: the Journal
output for this scenario, saved as a test suite artifact, actually shows that
the expected denial occurred.

I think that when we use this step after "I do not see […]", which calls
waitVanish, Cucumber + Sikuli can possibly win the race against systemd-journald
and then we expect a log message that was not registered yet.

So, let's try up to 10 times to find the log message we want and drop the
ability to customize that delay (which is not used anywhere).

I've seen a number of cases where dogtail thinks it has clicked the button
but the zenity dialog remains displayed and Tor Browser does not start.
Let's hope that explicitly giving focus to the button (and thus, to the dialog)
fixes that.

I did not manage to make it robust enough with Firefox 60 and this test was
never meant to exercise the HTML5 player: it was introduced
(commit:136db50c) to ensure our AppArmor
confinement for Tor Browser did not break audio playback, so let's
do this and not more, just like we're doing for the video test as well.

… and incidentally, this image can be used by future tests of other GTK3 apps.

Mixing Dogtail and Sikuli is tricky: in this case, Dogtail pretended it had
clicked the Print button, but that was before the output file selection dialog
had disappeared, so that click did nothing. So let's do the same as in the
Evince test, that works in a robust manner.

It now uses the system GTK3 dialog.

Refs: #15332

The recently introduced always-on Sikuli image candidate search makes
wait() not work so great when expected to fail (as in the "do not"
case of this step) so let's use waitVanish() instead.

And, while we're at it, let's not use the FindFailed override for
waitVanish() -- it was purely a mistake that it was overridden!

Will-fix: #14929

The recently introduced always-on Sikuli image candidate search makes
wait() not work so great when expected to fail (as in the "do not"
case of this step) so let's use waitVanish() instead.

And, while we're at it, let's not use the FindFailed override for
waitVanish() -- it was purely a mistake that it was overridden!

Will-fix: #14929

Hypothesis: #14772 is due to a race occurring after `step "the time
has synced"`, namely that the systemd units that will start when the
time is synced (and probably the same check is used for this as in
that step) haven't necessarily finished when we run `systemctl
is-system-running`. So let's just give it some more time.

Will-fix: #14772

intrigeri authored Oct 04, 2017 and anonym committed Dec 04, 2017

Listing the units is not enough: in most cases I've seen, is-system-running
returns "starting" which means the job queue is not empty, and to debug that we
need the list of jobs.

... instead of using the Tor Browser: since version 7.0.8 it fails to
render local pages (like our docs) due to #14962.

Refs: #14962

Hypothesis: #14772 is due to a race occurring after `step "the time
has synced"`, namely that the systemd units that will start when the
time is synced (and probably the same check is used for this as in
that step) haven't necessarily finished when we run `systemctl
is-system-running`. So let's just give it some more time.

Will-fix: #14772

Listing the units is not enough: in most cases I've seen, is-system-running
returns "starting" which means the job queue is not empty, and to debug that we
need the list of jobs.

On my development laptop and on my local Jenkins, I see the "The Tor Browser
directory is usable" scenario fail randomly when the system is under load.
Bumping a bit the timeout fixes that.

Our "custom" Root Terminal from #12738 is shown as a search result for
"GNOME Terminal", leading to it being incorrectly picked some times.

[This should not have been reverted in commit
889964b1 so I had to cherry-pick it
back from past history.]

Test suite: take into account that click-to-play is not required anymore for WebM videos in Tor Browser (refs: #14586).

They are not robust enough, and will have to be finished
later (#14656) so the rest of this branch can be merged in time for
Tails 3.2~rc1.

Refs: #12738, #14656

We wait for the icons to appear on the desktop, which should be enough.
If not, then we can reintroduce a similar check for another icon.

Our "custom" Root Terminal from #12738 is shown as a search result for
"GNOME Terminal", leading to it being incorrectly picked some times.

While we're at it, let's Dogtailify some of our old GNOME Terminal
interaction.

Refs: #12738