Work around spurious Travis CI failures in WebView selection test

We can't rely on HasSelection() returning true immediately after calling
SelectAll() because this operation (as almost all the other ones) is
asynchronous with WebKit and might not have completed yet when we check
for the selection existence.

There doesn't seem to be any way to wait for its completion, so just
poll the selection state for some time before deciding that it hasn't
been updated. In practice, just a couple of ms is enough on a normal
machine, but wait up to 50ms on Travis just to be on the safe side.

Note that to reliably reproduce the problem locally it's enough to run
"taskset 1 ./test_gui -c Selection WebView", i.e. pin both the main and
WebKit processes to the same CPU.

tests/controls/webtest.cpp

@@ -24,6 +24,9 @@
 #if wxUSE_WEBVIEW_IE
     #include "wx/msw/webview_ie.h"
 #endif
+#if wxUSE_WEBVIEW_WEBKIT2
+    #include "wx/stopwatch.h"
+#endif
 
 //Convenience macro
 #define ENSURE_LOADED CHECK( m_loaded->WaitEvent() )
@@ -195,6 +198,15 @@ TEST_CASE_METHOD(WebViewTestCase, "WebView", "[wxWebView]")
 
         m_browser->SelectAll();
 
+#if wxUSE_WEBVIEW_WEBKIT2
+        // With WebKit SelectAll() sends a request to perform the selection to
+        // another process via proxy and there doesn't seem to be any way to
+        // wait until this request is actually handled, so loop here for some a
+        // bit before giving up.
+        for ( wxStopWatch sw; !m_browser->HasSelection() && sw.Time() < 50; )
+            wxMilliSleep(1);
+#endif // wxUSE_WEBVIEW_WEBKIT2
+
         CHECK(m_browser->HasSelection());
         CHECK(m_browser->GetSelectedText() == "Some strong text");