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.
(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.
<rdar://problem/8749946>
(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?
Landed failing expected results in r73632.
Created attachment 76288 [details] fixed the tests
Comment on attachment 76288 [details] fixed the tests I lied this doesn't work :(
(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.
Created attachment 76290 [details] adds a magic console.log
Created attachment 76292 [details] Added sad comments
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).