Summary: | [GTK] and [Win] TestWebKitAPI/WebKit2/TestSpacebarScrolling fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Carlos Garcia Campos <cgarcia> | ||||||
Component: | Tools / Tests | Assignee: | Roger Fong <roger_fong> | ||||||
Status: | NEW --- | ||||||||
Severity: | Normal | CC: | bugs-noreply, eric, jhoneycutt, pnormand, roger_fong, thorton | ||||||
Priority: | P2 | Keywords: | Gtk | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Carlos Garcia Campos
2012-04-26 07:54:07 PDT
[ 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 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... 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. Created attachment 166322 [details]
patch
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. 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: https://bugs.webkit.org/show_bug.cgi?id=97946 Created attachment 166552 [details]
patch
Hmm can I get an r+/- from someone? 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. Comment added, 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.
|