From the "bad run" testlogs:
[16662:16662:0412/210011.391144:WARNING:CONSOLE(283)] "<webview>: The load has aborted with error -102: ERR_CONNECTION_REFUSED.", source: extensions::webViewEvents (283)
../../chrome/browser/chromeos/login/test/js_checker.cc:61: Failure
Value of: GetBool(expression)
  Actual: false
Expected: true
$('signin-frame').src.indexOf('#identifier') != -1

It seems that after |WaitForGaiaPageLoad()| has returned, |ExpectIdentifierPage()| fails on this step:

JsExpect("$('signin-frame').src.indexOf('#identifier') != -1");

Interestingly, many other tests in the same class also start with |WaitForGaiaPageLoad()|/|ExpectIdentifierPage()|, so I don't think this flake should be specific to this test.

Plan of record:
- I'll try see where the webview load errors come from and if they're also present in a good run.
- Maybe WaitForGaiaPageLoad returns too early.
- Maybe |OobeBaseTest::InitHttpsForwarders| returns too early.
- Maybe something else is happening :-)

Flaked again @ https://ci.chromium.org/buildbot/tryserver.chromium.chromiumos/linux-chromeos-rel/101616

Flaky tests are P1 (blocks CQ, affects all devs). Please disable this test ASAP if not landing a quick fix. Thanks!

The flake mentioned in Comment #3 was in WebviewLoginTest.Basic, but this also has the WaitForGaiaPageLoad/ExpectIdentifierPage leading steps, so this confirms the theory that it's not only happening for *StoragePartitionHandling.

Xiyuan, do you have any idea from the top of your head?
Otherwise I can investigate/disable the test for now on Monday.

It looks like WaitForGaiaPageLoad should only finish after a message has been received from within the webview, so it's unlikely that the HTTPS forwarder would not be initialized correctly.

The new failures are related to this CL:
https://chromium-review.googlesource.com/c/1011287/

It changes postMessage behavior a bit. alexmos@ tried to fix the flakyness.

And as alexmos@ pointed out in his CL, WaitForGaiaPageLoad might not be enough. We need additional signals for wait for the sign-in page inside the webview to finish the transition. He added wait for "backButton" event from authenticator.js but seems still not good enough.

BTW, the CL got revertet on ToT right now.

Thanks, that makes sense. I'll think about what we can do on monday too.

Yes, https://chromium-review.googlesource.com/c/1011287/ is already reverted.  I think this flakiness is because WaitForGaiaPageLoad() returns too early in this case.  It only waits for the 'ready' event from the gaia page, but the subsequent ExpectIdentifierPage() checks properties such as #identifier being in the location and back button visibility, which are triggered by a postMessage and modified after the 'ready' event is delivered.  My CL makes cross-process postMessages a bit slower (via PostTask; this is needed for correctness), and this includes messages to/from <webview>, so it exposes this race.

The reason this only showed up in the Basic test was because the others that use ExpectIdentifierPage() after WaitForGaiaPageLoad() were disabled -- BackButton is still disabled on ToT, and StoragePartitionHandling was temporarily disabled in  issue 832608  (I've re-enabled it since then).

I'll try to address this in my reland.

<triage> Moving to P3 and marking available due to lack of target milestone and activity, please update if this is a priority. </triage>