We need to look at it in detail, I don't know why it fails
[ FATAL ] ../Source/ThirdParty/gtest/include/gtest/internal/gtest-port.h:1059:: pthread_mutex_destroy(&mutex_)failed with error 16
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from WebKit2
[ RUN ] WebKit2.SpacebarScrolling
JS expression: isDocumentScrolled()
Tests failed: Programs/TestWebKitAPI/WebKit2/TestSpacebarScrolling
This also breaks on the Apple Windows port.
I thought it could have been a timing thing at first so I put a nice long loop into the SpaceBarScrolling.cpp could right before the failing EXPECT_JS_TRUE to see if it the page just didn't have time to scroll before the check. It still failed. So there's probably something goofy going on with the Windows TestWebKitAPI support, but for now, just switching the two lines will make the test pass.
Maybe it will work on gtk as well...
Same behaviour can be observed earlier in the test right after the first space press is simulated.
If you switch the second two lines to:
the test will fail on the first EXPECT_JS_TRUE because the spacebarkeypress has not yet actually happened.
The patch I'll land is a work around for this test but I'll file a new bug for the larger problem at hand.
Created attachment 166322 [details]
Comment on attachment 166322 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=166322&action=review
> + EXPECT_JS_TRUE(webView.page(), "textFieldContainsSpace()");
I think it would be interesting to know why this needs to happen before isDocumentScrolled() returns the correct value.
You should see if a 0-delay timeout also fixes this, and then it would be interesting to know what's different between Win/Mac wrt. isDocumentScrolled and spinning the runloop.
Disregard the patch. It defeats the purpose of the test. Making a new test that just disables the failing line on Win using an #if
Bug to track the larger problem at hand:
Created attachment 166552 [details]
Hmm can I get an r+/- from someone?
Comment on attachment 166552 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=166552&action=review
> +#if !PLATFORM(WIN)
You should put a comment here with the link to the relevant bugzilla bug here.
committed here: http://trac.webkit.org/changeset/130221
Leaving bug open in case GTK wants to do the same...
Attachment 166552 [details] was posted by a committer and has review+, assigning to Roger Fong for commit.