Bug 66514

Because this test times out.

the test introduced in https://trac.webkit.org/changeset/93369

I skipped the test in http://trac.webkit.org/changeset/93394.

Also see the bug 66551.

Does the test still time out if you commented out all but the first dt and dd?

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.

See http://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/qt/EventSenderQt.cpp#L561

(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?

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

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

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

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

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

Apparently, there's some Qt-specific bug here. Skipped again in http://trac.webkit.org/changeset/93549.

Jesus patch for bug #76821 seems to fix this one. Marking this bug as dependent of it.

It's still failing. See: https://bugs.webkit.org/show_bug.cgi?id=77102

Created attachment 167608 [details] Patch Unskipping test. The changes in testfonts solved this bug.

Comment on attachment 167608 [details] Patch OK.

Comment on attachment 167608 [details] Patch Clearing flags on attachment: 167608 Committed r130740: <http://trac.webkit.org/changeset/130740>

All reviewed patches have been landed. Closing bug.