Fixing testBrowsingPostEntryWithButton flakiness.

ios/chrome/browser/web/forms_egtest.mm

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import <XCTest/XCTest.h>
 
 #include "base/mac/scoped_nsobject.h"
 #include "base/memory/ptr_util.h"
 #include "base/strings/stringprintf.h"
 #include "base/strings/sys_string_conversions.h"
@@ skipping 328 matching lines @@
   // Check that the popup did not show
   id<GREYMatcher> resendWarning =
       chrome_test_util::ButtonWithAccessibilityLabelId(
           IDS_HTTP_POST_WARNING_RESEND);
   [[EarlGrey selectElementWithMatcher:resendWarning]
       assertWithMatcher:grey_nil()];
 
   [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