34069 2010-01-24 23:18:02 -0800 REGRESSION: editing/selection/doubleclick-beside-cr-span.html times out on Windows 2010-02-01 16:08:55 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 1 eric webkit-unassigned bweinstein hamaji morrita oldest_to_newest 184176 0 eric 2010-01-24 23:18:02 -0800 REGRESSION: editing/selection/doubleclick-beside-cr-span.html times out on Windows This seems to have started today. The windows bots were broken between r53763 and r53783, and I believe it the timeouts started happening during that down time. Added 6 days ago: http://trac.webkit.org/browser/trunk/LayoutTests/editing/selection/doubleclick-beside-cr-span.html 184560 1 hamaji 2010-01-26 04:45:54 -0800 Hmm... I'm not sure if this is a regression. I ran the test with r53763 and r53783. I didn't see significant differences between the results of them. I've also noticed this test is very slow on Windows (~24 secs on my slow machine). It seems eventSender.leapForward() actually waits on Windows? So, I'm guessing somehow windows bots become slow during the downtime, but I'm not sure at all. Anyway, if we want to make the bot green, we can change from leapForward(100) to leapForward(50). But, of course, if this is indicating an actual regression, this change just hides the regression... 184588 2 morrita 2010-01-26 07:25:10 -0800 Thanks for the investigation, Hamaji-san. I don't have windows box... > It seems eventSender.leapForward() actually waits on Windows? At a glance, the code appears to literally sleep. in WebKitTools/DumpRenderTree/win/EventSender.cpp, ---- static JSValueRef leapForwardCallback(JSContextRef context, JSObjectRef function, JSObjectRef thisObject, size_t argumentCount, const JSValueRef arguments[], JSValueRef* exception) { if (argumentCount > 0) { msgQueue[endOfQueue].delay = JSValueToNumber(context, arguments[0], exception); } ... } and void replaySavedEvents(HRESULT* oleDragAndDropReturnValue) { ... if (msgQueue[startOfQueue].delay) { ::Sleep(msgQueue[startOfQueue].delay); msgQueue[startOfQueue].delay = 0; } ... } ---- I guess it would take long time to run the test case, and the case would be around timeout border, timed out recently with small overhead added somewhere. For this reason, I think making sleep time shorter is reasonable at this time, although further investigation to speedup windows layout test is required. 186351 3 47828 hamaji 2010-02-01 03:32:19 -0800 Created attachment 47828 Patch v1 186352 4 hamaji 2010-02-01 03:35:42 -0800 I ran the tests with r53762 on build bot and it timed out. So, I guess the timeout happened even before r53762 (or buildbot somehow becomes slower during the windows bots outage?). http://build.webkit.org/builders/Windows%20Debug%20%28Tests%29/builds/9253 186366 5 47828 eric 2010-02-01 05:17:21 -0800 Comment on attachment 47828 Patch v1 leapForward does not actually sleep (at least not on the mac). Instead it just queues the next event with a different time during event playback. 186371 6 hamaji 2010-02-01 05:29:29 -0800 (In reply to comment #5) > (From update of attachment 47828 [details]) > leapForward does not actually sleep (at least not on the mac). Instead it just > queues the next event with a different time during event playback. Yeah, on Mac, leapForward doesn't sleep. However, on Windows, it seems leapForward sleeps as Morita-san said. 186429 7 47828 darin 2010-02-01 08:14:10 -0800 Comment on attachment 47828 Patch v1 The whole idea of leapForward was to not require sleeping, but I suppose it's OK to make this change. 186636 8 47828 hamaji 2010-02-01 16:08:47 -0800 Comment on attachment 47828 Patch v1 Clearing flags on attachment: 47828 Committed r54166: <http://trac.webkit.org/changeset/54166> 186638 9 hamaji 2010-02-01 16:08:55 -0800 All reviewed patches have been landed. Closing bug. 47828 2010-02-01 03:32:19 -0800 2010-02-01 16:08:46 -0800 Patch v1 bug-34069-20100201033217.patch text/plain 1239 hamaji ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCBhNTE0MzU5Li4wNjljMmNhIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMTAtMDEt MzEgIFNoaW5pY2hpcm8gSGFtYWppICA8aGFtYWppQGNocm9taXVtLm9yZz4KKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBSRUdSRVNTSU9OOiBlZGl0aW5n L3NlbGVjdGlvbi9kb3VibGVjbGljay1iZXNpZGUtY3Itc3Bhbi5odG1sIHRpbWVzIG91dCBvbiBX aW5kb3dzCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0z NDA2OQorCisgICAgICAgIE1ha2UgdGhlIHNsZWVwIHRpbWUgc2hvcnRlciBhcyB0aGlzIHRlc3Qg dGltZWQgb3V0IG9uIFdpbmRvd3MgYm90LgorCisgICAgICAgICogZWRpdGluZy9zZWxlY3Rpb24v ZG91YmxlY2xpY2stYmVzaWRlLWNyLXNwYW4uaHRtbDoKKwogMjAxMC0wMS0zMSAgS2VudCBUYW11 cmEgIDx0a2VudEBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgRGFyaW4gQWRs ZXIuCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9lZGl0aW5nL3NlbGVjdGlvbi9kb3VibGVjbGlj ay1iZXNpZGUtY3Itc3Bhbi5odG1sIGIvTGF5b3V0VGVzdHMvZWRpdGluZy9zZWxlY3Rpb24vZG91 YmxlY2xpY2stYmVzaWRlLWNyLXNwYW4uaHRtbAppbmRleCA0NDcwZDA1Li5iYmMwNTg2IDEwMDY0 NAotLS0gYS9MYXlvdXRUZXN0cy9lZGl0aW5nL3NlbGVjdGlvbi9kb3VibGVjbGljay1iZXNpZGUt Y3Itc3Bhbi5odG1sCisrKyBiL0xheW91dFRlc3RzL2VkaXRpbmcvc2VsZWN0aW9uL2RvdWJsZWNs aWNrLWJlc2lkZS1jci1zcGFuLmh0bWwKQEAgLTI5LDcgKzI5LDcgQEAgZnVuY3Rpb24gZG91Ymxl Q2xpY2tQb3NpdGlvbihwb3MpCiAgICAgZXZlbnRTZW5kZXIubW91c2VEb3duKCk7CiAgICAgZXZl bnRTZW5kZXIubGVhcEZvcndhcmQoMSk7CiAgICAgZXZlbnRTZW5kZXIubW91c2VVcCgpOwotICAg IGV2ZW50U2VuZGVyLmxlYXBGb3J3YXJkKDEwMCk7CisgICAgZXZlbnRTZW5kZXIubGVhcEZvcndh cmQoNTApOwogICAgIGV2ZW50U2VuZGVyLm1vdXNlRG93bigpOwogICAgIGV2ZW50U2VuZGVyLmxl YXBGb3J3YXJkKDEpOwogICAgIGV2ZW50U2VuZGVyLm1vdXNlVXAoKTsK