66514 2011-08-18 17:00:54 -0700 [Qt] editing/selection/caret-at-bidi-boundary.html fails 2012-10-09 02:04:52 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 76821 1 rniwa webkit-unassigned cshu kbalazs mrobinson ossy rafael.lobo rhodovan.u-szeged tonikitoo webkit.review.bot yael zoltan oldest_to_newest 453498 0 rniwa 2011-08-18 17:00:54 -0700 The test added by http://trac.webkit.org/changeset/93369 is failing on Qt. Unfortunately, I can't see the diff on http://build.webkit.org/results/Qt%20Linux%20Release/r93369%20(36616)/results.html. Could either one of you run the test locally tell me what the diff is? 453698 1 ossy 2011-08-19 01:42:18 -0700 Because this test times out. 453699 2 ossy 2011-08-19 01:43:19 -0700 the test introduced in https://trac.webkit.org/changeset/93369 453740 3 zoltan 2011-08-19 04:38:30 -0700 I skipped the test in http://trac.webkit.org/changeset/93394. 453885 4 rniwa 2011-08-19 09:50:53 -0700 Also see the bug 66551. 453887 5 rniwa 2011-08-19 09:52:54 -0700 Does the test still time out if you commented out all but the first dt and dd? 454272 6 rniwa 2011-08-19 18:49:20 -0700 Ah, so this is caused by Qt's DRT actually sleeping for the amount of time leapForward is called upon. This is not how other ports implement leapForward (except Windows port which apparently has the same behavior). The point of leapForward is so that you can call it as many time as you want with any delay as you wish without actually delaying or sleeping DRT. 454273 7 rniwa 2011-08-19 18:50:06 -0700 See http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/qt/EventSenderQt.cpp#L561 454410 8 mrobinson 2011-08-21 09:56:44 -0700 (In reply to comment #6) > Ah, so this is caused by Qt's DRT actually sleeping for the amount of time leapForward is called upon. This is not how other ports implement leapForward (except Windows port which apparently has the same behavior). The point of leapForward is so that you can call it as many time as you want with any delay as you wish without actually delaying or sleeping DRT. I tried in vain to remove the actual sleep from the GTK+ DRT. GTK+ internals didn't allow it though -- it broke drag and drop completely. Does this test really need to leap forward one entire second for each loop iteration? Why not just reduce the amount of time for now, since fixing all of these platforms is non-trivial? 454414 9 rniwa 2011-08-21 12:16:03 -0700 (In reply to comment #8) > I tried in vain to remove the actual sleep from the GTK+ DRT. GTK+ internals didn't allow it though -- it broke drag and drop completely. Does this test really need to leap forward one entire second for each loop iteration? Why not just reduce the amount of time for now, since fixing all of these platforms is non-trivial? So if I reduce the amount of time, to say 100ms, then the test still time outs because my test clicks on every pixel on a text run to verify that the caret is placed on the correct location for several test cases. Even if the text was only 50 pixels long, it'll take 5 seconds at minimum. On the other hand, if I reduce the waiting time too much (even 100ms is too small), then DRT thinks I'm double/triple clicking and fail. We might be able to get away with this problem if we had a way to clear click count in EventHandler. 454614 10 mrobinson 2011-08-22 08:43:10 -0700 (In reply to comment #9) > We might be able to get away with this problem if we had a way to clear click count in EventHandler. Another possible solution to avoid leaping forward is to click once at enough distance from the original clicks to reset the internal click counter. This is at least how Windows and GTK+ work. I'm not sure about Mac, Qt and Chromium. 454700 11 rniwa 2011-08-22 11:02:54 -0700 (In reply to comment #10) > (In reply to comment #9) > > > We might be able to get away with this problem if we had a way to clear click count in EventHandler. > > Another possible solution to avoid leaping forward is to click once at enough distance from the original clicks to reset the internal click counter. This is at least how Windows and GTK+ work. I'm not sure about Mac, Qt and Chromium. That IS an brilliant idea! It works on Windows at least. Let me make a patch. 454716 12 mrobinson 2011-08-22 11:12:39 -0700 (In reply to comment #11) > That IS an brilliant idea! It works on Windows at least. Let me make a patch. I think a long term solution might be to have some EventSender hooks for sending a specific number of clicks. Something like eventSender.doubleClick or eventSender.click(2). That way if there are platform-specific ways to enforce click counts, we can push that to port code. 454762 13 rniwa 2011-08-22 11:46:38 -0700 (In reply to comment #12) > (In reply to comment #11) > > > That IS an brilliant idea! It works on Windows at least. Let me make a patch. > > I think a long term solution might be to have some EventSender hooks for sending a specific number of clicks. Something like eventSender.doubleClick or eventSender.click(2). That way if there are platform-specific ways to enforce click counts, we can push that to port code. I uploaded a patch on the bug 66551 per your suggestion. 454968 14 rniwa 2011-08-22 15:03:26 -0700 Apparently, there's some Qt-specific bug here. Skipped again in http://trac.webkit.org/changeset/93549. 541702 15 rafael.lobo 2012-01-24 14:31:34 -0800 Jesus patch for bug #76821 seems to fix this one. Marking this bug as dependent of it. 543139 16 kbalazs 2012-01-26 07:22:06 -0800 It's still failing. See: https://bugs.webkit.org/show_bug.cgi?id=77102 737046 17 167608 tullio.lucena 2012-10-08 14:27:45 -0700 Created attachment 167608 Patch Unskipping test. The changes in testfonts solved this bug. 737555 18 167608 yutak 2012-10-09 01:57:13 -0700 Comment on attachment 167608 Patch OK. 737562 19 167608 webkit.review.bot 2012-10-09 02:04:47 -0700 Comment on attachment 167608 Patch Clearing flags on attachment: 167608 Committed r130740: <http://trac.webkit.org/changeset/130740> 737563 20 webkit.review.bot 2012-10-09 02:04:52 -0700 All reviewed patches have been landed. Closing bug. 167608 2012-10-08 14:27:45 -0700 2012-10-09 02:04:46 -0700 Patch patch.diff text/plain 1152 tullio.lucena ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCA4MjgxZmRiLi40ZTdjZDhjIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9DaGFuZ2VM b2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAKKzIwMTItMTAt MDggIFR1bGxpbyBMdWNlbmEgIDx0dWxsaW8ubHVjZW5hQG9wZW5ib3NzYS5vcmc+CisKKyAgICAg ICAgW1F0XSBlZGl0aW5nL3NlbGVjdGlvbi9jYXJldC1hdC1iaWRpLWJvdW5kYXJ5Lmh0bWwgZmFp bHMKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTY2NTE0 CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVW5za2lw cGluZyB0ZXN0LiBUaGUgdXBkYXRlIGluIHRlc3Rmb250cyBzb2x2ZWQgdGhpcyBidWcuCisKKyAg ICAgICAgKiBwbGF0Zm9ybS9xdC9UZXN0RXhwZWN0YXRpb25zOgorCiAyMDEyLTEwLTA4ICBKdWxp ZW4gQ2hhZmZyYWl4ICA8amNoYWZmcmFpeEB3ZWJraXQub3JnPgogCiAgICAgICAgIFVucmV2aWV3 ZWQgQ2hyb21pdW0gZ2FyZGVuaW5nLgpkaWZmIC0tZ2l0IGEvTGF5b3V0VGVzdHMvcGxhdGZvcm0v cXQvVGVzdEV4cGVjdGF0aW9ucyBiL0xheW91dFRlc3RzL3BsYXRmb3JtL3F0L1Rlc3RFeHBlY3Rh dGlvbnMKaW5kZXggMzY5OTgxMC4uMjM4MTI5OCAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvcGxh dGZvcm0vcXQvVGVzdEV4cGVjdGF0aW9ucworKysgYi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9xdC9U ZXN0RXhwZWN0YXRpb25zCkBAIC04NTQsOSArODU0LDYgQEAgZWRpdGluZy9zZWxlY3Rpb24vY2Fy ZXQtcnRsLmh0bWwKICMgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTQx OTE4CiBlZGl0aW5nL3NlbGVjdGlvbi81MTk1MTY2LTEuaHRtbAogCi0jIGh0dHBzOi8vYnVncy53 ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD02NjUxNAotZWRpdGluZy9zZWxlY3Rpb24vY2FyZXQt YXQtYmlkaS1ib3VuZGFyeS5odG1sCi0KICMgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19i dWcuY2dpP2lkPTY2NDMxCiBlZGl0aW5nL3NlbGVjdGlvbi9jb2xsYXBzZS1zZWxlY3Rpb24taW4t YmlkaS5odG1sCiAK