Bug 84961 – [GTK] and [Win] TestWebKitAPI/WebKit2/TestSpacebarScrolling fails

• Component: Tools / Tests
• Status: NEW

[Carlos Garcia Campos]

We need to look at it in detail, I don't know why it fails

[Carlos Garcia Campos]

[ 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
../Tools/TestWebKitAPI/Tests/WebKit2/SpacebarScrolling.cpp:92: Failure
JS expression: isDocumentScrolled()
       Actual: false
     Expected: true
Tests failed: Programs/TestWebKitAPI/WebKit2/TestSpacebarScrolling

[Roger Fong]

This also breaks on the Apple Windows port.

I got it to work by adding the second call to EXPECT_JS_TRUE(webView.page(), "textFieldContainsSpace()") to after the call to isDocumentScrolled. At least on Windows if you don't re-enter the javascript context first after simulating the space bar key press the document won't actually scroll.

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...

[Roger Fong]

Same behaviour can be observed earlier in the test right after the first space press is simulated. 

    webView.simulateSpacebarKeyPress();

    EXPECT_JS_FALSE(webView.page(), "isDocumentScrolled()");
    EXPECT_JS_TRUE(webView.page(), "textFieldContainsSpace()");

If you switch the second two lines to:

    webView.simulateSpacebarKeyPress();

    EXPECT_JS_TRUE(webView.page(), "textFieldContainsSpace()");
    EXPECT_JS_FALSE(webView.page(), "isDocumentScrolled()");
 
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.

[Roger Fong]

Created attachment 166322 [details]
patch

[Tim Horton]

Comment on attachment 166322 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=166322&action=review

> Tools/TestWebKitAPI/Tests/WebKit2/SpacebarScrolling.cpp:92
> +    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.

[Roger Fong]

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

[Roger Fong]

Bug to track the larger problem at hand:
https://bugs.webkit.org/show_bug.cgi?id=97946

[Roger Fong]

Created attachment 166552 [details]
patch

[Roger Fong]

Hmm can I get an r+/- from someone?

[Anders Carlsson]

Comment on attachment 166552 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=166552&action=review

> Tools/TestWebKitAPI/Tests/WebKit2/SpacebarScrolling.cpp:92
> +#if !PLATFORM(WIN)

You should put a comment here with the link to the relevant bugzilla bug here.

[Roger Fong]

Comment added,
committed here: http://trac.webkit.org/changeset/130221

Leaving bug open in case GTK wants to do the same...

[Eric Seidel (no email)]

Attachment 166552 [details] was posted by a committer and has review+, assigning to Roger Fong for commit.