// Execute script with callback.                                               
  __block std::unique_ptr<base::Value> execution_result;
  web_state_->ExecuteJavaScript(base::UTF8ToUTF16("window.foo"),
                                base::BindBlock(^(const base::Value* value) {
                                  ASSERT_TRUE(value);
                                  execution_result = value->CreateDeepCopy();
                                }));
  base::test::ios::WaitUntilCondition(^bool() {
    return execution_result.get();
  });


Looking at the code, if the test fails and |value| is NULL in the callback, we will end up waiting forever because |execution_result| will never be set to a non-NULL value.

Instead of the ASSERT_TRUE, maybe we should switch to an EXPECT_TRUE and set execution_result to some failure sentinel value?  And maybe switch to WaitUntilConditionOrTimeout, just in case the JS handler is totally broken and never runs the callback at all?

I think that ASSERT_TRUE is the right thing to do. ASSERT means: "there is no value in continuing this test", which is true in this case. Why do you think we'll be waiting forever? ASSERT suppose to terminate the test execution.

base::test::ios::WaitUntilCondition hangs forever only locally, on bots it is killed by timeout. I remember we discussed this and agreed that WaitUntilCondition should not hang indefinitely but timeout in a minute or so. 
I would prefer not to use WaitUntilConditionOrTimeout just because base::test::ios::WaitUntilCondition is broken. base::test::ios::WaitUntilCondition is used all over the places and fixing one place will not solve the problem.

This test failed only once out of 20 runs. Will keep an eye on it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7647e35b78ecf8f6ff9566728d7063760ec65ee4

commit 7647e35b78ecf8f6ff9566728d7063760ec65ee4
Author: eugenebut <eugenebut@chromium.org>
Date: Fri Jan 06 19:53:25 2017

[ios] Moved ASSERT_TRUE out of block in WebStateTest.ScriptExecution.

ASSERT_TRUE stops test execution by retuning, which will not stop the
test if return is called from the block.

BUG= 678942 

Review-Url: https://codereview.chromium.org/2611283003
Cr-Commit-Position: refs/heads/master@{#442014}

[modify] https://crrev.com/7647e35b78ecf8f6ff9566728d7063760ec65ee4/ios/web/web_state/web_state_impl_unittest.mm

Are the timeout issues also on other configs?

For example:
ios_web_unittests (iPhone 5s iOS 9.3.2) on iOS-9.3.2 Test timed out.
https://uberchromegw.corp.google.com/i/internal.bling.main/builders/iphone9-device-x64/builds/8890

Is it related?

Link from comment #6 is unrelated. That timeout happens because bots run FLAKY_ tests, which should probably be disabled instead.

Does not flake anymore. I guess WebView was simply evicted by OS and script execution failed. If my guess is correct that we can't fix that.