Fixing testBrowsingPostEntryWithButton flakiness.

ios/chrome/browser/web/forms_egtest.mm

Index: ios/chrome/browser/web/forms_egtest.mm
diff --git a/ios/chrome/browser/web/forms_egtest.mm b/ios/chrome/browser/web/forms_egtest.mm
index 2210492ffa19019a3b7cd16d853daf33248f394a..0387d378297af4e69bc6f17078bca983df645b99 100644
--- a/ios/chrome/browser/web/forms_egtest.mm
+++ b/ios/chrome/browser/web/forms_egtest.mm
@@ -346,4 +346,31 @@ - (void)testRepostFormCancellingAfterRedirect {
   [self waitForExpectedResponse:"GET"];
 }
 
+// Tests that pressing the button on a POST-based form changes the page and that
+// the back button works as expected afterwards.
+- (void)testGoBackButtonAfterFormSubmission {
+  // Create map of canned responses and set up the test HTML server.
+  std::map<GURL, std::string> responses;
+  const GURL URL = web::test::HttpServer::MakeUrl("http://postEntryWithButton");
+  const GURL destinationURL = web::test::HttpServer::MakeUrl("http://foo");
+  // This is a page with a button that posts to the destination.
+  responses[URL] = base::StringPrintf(
+      "<form action='%s' method='post'>"
+      "<input value='button' type='submit' id='button'></form>",
+      destinationURL.spec().c_str());
+  // This is the page that should be showing at the end of the test.
+  responses[destinationURL] = "bar!";
+  web::test::SetUpSimpleHttpServer(responses);
+
+  [ChromeEarlGrey loadURL:URL];
+  chrome_test_util::TapWebViewElementWithId("button");
+  [ChromeEarlGrey
+      waitForOmniboxText:base::SysUTF8ToNSString(destinationURL.GetContent())];

[Eugene But (OOO till 7-30), 2017/04/08 00:16:27]

Should |waitForOmniboxText:| take std::string instead? I feel that tests will
either pass URL.GetContent() or string literal, so std::string would lead to a
cleaner code.

But also we have a bunch of tests that wait for web view with specific text.
Should this test also wait for web view with specific text (so we don't have to
add new API)?

[liaoyuke, 2017/04/08 00:43:07]

Yeah, I thought about that, but I went with NSString* because I want it to be
consistent with other methods in this file. 

One bigger question is that, wait for web view with specific text requires that
the test output something to the web view, and the test may still want to verify
that omnibox changed. Would it be simpler and cleaner if the test just wait for
the omnibox?

[Eugene But (OOO till 7-30), 2017/04/08 00:55:09]

Should we lean towards API convenience rather that API consistency?
All other tests are waiting for text. Most of the tests will not be able to wait
for omnibox URL, and waitForWebViewWithText has to exist. That is already
established pattern and it is better to have fewer "waitFor" APIs and fewer
different ways to wait for something. WDYT?

+
+  // Go back and verify the browser navigates to the original URL.
+  [self goBack];
+  [[EarlGrey selectElementWithMatcher:OmniboxText(URL.GetContent())]
+      assertWithMatcher:grey_notNil()];
+}
+
 @end