REGRESSION: caret-ltr-right.html, caret-rtl-2-left.html, and caret-rtl-right.html fail on Windows bots

• Component: HTML Editing
• Status: RESOLVED LATER

[Ryosuke Niwa]

The following tests are failing on Windows bots:
editing/selection/caret-ltr-right.html
editing/selection/caret-rtl-2-left.html
editing/selection/caret-rtl-right.html

The problem is that the selection is not collapsed.

--- /home/buildbot/slave/WebKit-BuildSlave/win-release-tests/build/layout-test-results/editing/selection/caret-ltr-right-expected.txt	2010-12-08 23:56:07.323441300 -0800
+++ /home/buildbot/slave/WebKit-BuildSlave/win-release-tests/build/layout-test-results/editing/selection/caret-ltr-right-actual.txt	2010-12-08 23:56:07.322441300 -0800
@@ -11,7 +11,8 @@
         RenderText {#text} at (11,11) size 74x23
           text run at (11,11) width 74: "WebKit2"
       RenderBlock (anonymous) at (0,97) size 784x18
-        RenderText {#text} at (0,0) size 39x18
-          text run at (0,0) width 39: "PASS"
-        RenderBR {BR} at (39,0) size 0x18
-caret: position 7 of child 0 {#text} of child 3 {DIV} of body
+        RenderText {#text} at (0,0) size 186x18
+          text run at (0,0) width 186: "FAIL: selection not collapsed"
+        RenderBR {BR} at (186,0) size 0x18
+selection start: position 0 of child 0 {#text} of child 3 {DIV} of body
+selection end:   position 7 of child 0 {#text} of child 3 {DIV} of body

The main logic of these tests are implemented in http://trac.webkit.org/browser/trunk/LayoutTests/editing/selection/resources/caret-edge-shared.js
15	    eventSender.mouseMoveTo(div.offsetLeft + x, div.offsetTop + div.offsetHeight / 2);
16	    eventSender.leapForward(200);
17	    eventSender.mouseDown();
18	    eventSender.leapForward(200);
19	    eventSender.mouseUp();

I'm emulating to click on the left or the right of LTR/RTL text but maybe I leapForward too much?
Or maybe we're setting focus to content editable area automatically and it's messing with selection.

[Adam Roben (:aroben)]

(In reply to comment #0)
> The main logic of these tests are implemented in http://trac.webkit.org/browser/trunk/LayoutTests/editing/selection/resources/caret-edge-shared.js
> 15        eventSender.mouseMoveTo(div.offsetLeft + x, div.offsetTop + div.offsetHeight / 2);
> 16        eventSender.leapForward(200);
> 17        eventSender.mouseDown();
> 18        eventSender.leapForward(200);
> 19        eventSender.mouseUp();
> 
> I'm emulating to click on the left or the right of LTR/RTL text but maybe I leapForward too much?
> Or maybe we're setting focus to content editable area automatically and it's messing with selection.

leapForward doesn't work on Windows. If the test relies on it then it is not surprising that it is failing.

[Adam Roben (:aroben)]

<rdar://problem/8749946>

[Brian Weinstein]

(In reply to comment #1)
> (In reply to comment #0)
> > The main logic of these tests are implemented in http://trac.webkit.org/browser/trunk/LayoutTests/editing/selection/resources/caret-edge-shared.js
> > 15        eventSender.mouseMoveTo(div.offsetLeft + x, div.offsetTop + div.offsetHeight / 2);
> > 16        eventSender.leapForward(200);
> > 17        eventSender.mouseDown();
> > 18        eventSender.leapForward(200);
> > 19        eventSender.mouseUp();
> > 
> > I'm emulating to click on the left or the right of LTR/RTL text but maybe I leapForward too much?
> > Or maybe we're setting focus to content editable area automatically and it's messing with selection.
> 
> leapForward doesn't work on Windows. If the test relies on it then it is not surprising that it is failing.

Should we check in failing results and reference this bug?

[Brian Weinstein]

Landed failing expected results in r73632.

[Ryosuke Niwa]

Created attachment 76288 [details]
fixed the tests

[Ryosuke Niwa]

Comment on attachment 76288 [details]
fixed the tests

I lied this doesn't work :(

[Ryosuke Niwa]

(In reply to comment #6)
> (From update of attachment 76288 [details])
> I lied this doesn't work :(

Apparently, Windows DRT is flaky.  The test passes when I insert console.log but doesn't pass when there's no log.  Also, changing the style of div seems to help sometimes.

Adam & Brian, could you look into this?  There's definitely something weird going on but I can't tell whether it's a bug in DRT or in WebCore that happens to only reproduce in Windows.

[Ryosuke Niwa]

Created attachment 76290 [details]
adds a magic console.log

[Ryosuke Niwa]

Created attachment 76292 [details]
Added sad comments

[Eric Seidel (no email)]

Comment on attachment 76292 [details]
Added sad comments

Please file a bug about remove the console.log, and link to the bug (in a comment) next to the log (or in the log itself).