GitLab

The tests were employing the following pattern:
1. Launch a flow that should result in a certain event occurring (e.g.,
   a navigation that should result in a language determined observer
   callback)
2. Create a waiter to observe the event and wait

Most of the time this works just fine, but it's subject to a race
wherein the event is fired as part of step 1. When this flow occurs,
the test will end up waiting forever and timing out. In particular, this
case is possible in the flow of navigating to a webpage and waiting for
the callback that the language was determined, which means that all of
the tests in this suite were subject to flake across all platforms
(this can be seen from
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=weblayer_browsertests&tests=TranslateBrowserTest.*).

This CL fixes the bug by ensuring that the waiters are created *before*
step 1 in each instance of the above flow. There are long-lived waiters
for each event of interest that are reset just prior to a new instance
of the above flow. As the waiters by design quit their RunLoop when
they receive the event of interest (whether they have yet received a
call to Wait() or not), having the waiters pre-created ensures that the
observation will work whether the event occurs as part of step 1 or
subsequent to step 2.

To verify, I ran the translate browsertest suite 100 times locally with
logging added to detect this race condition. Prior to making the change
in this CL I saw 3 failed tests that were indeed subject to this race.
After the change I saw no failed tests.

Bug: 1128384
Change-Id: I141dac490a0b486da3eff66a7bca7075cc76e403
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2410488Reviewed-by: Clark DuVall <cduvall@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#807072}