Bug 50731 - REGRESSION: caret-ltr-right.html, caret-rtl-2-left.html, and caret-rtl-right.html fail on Windows bots
Summary: REGRESSION: caret-ltr-right.html, caret-rtl-2-left.html, and caret-rtl-right....
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P1 Normal
Assignee: Ryosuke Niwa
URL:
Keywords: InRadar, LayoutTestFailure, PlatformOnly
Depends on:
Blocks:
 
Reported: 2010-12-08 19:54 PST by Ryosuke Niwa
Modified: 2012-06-03 00:25 PDT (History)
4 users (show)

See Also:


Attachments
fixed the tests (45.47 KB, patch)
2010-12-10 18:56 PST, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
adds a magic console.log (46.63 KB, patch)
2010-12-10 19:50 PST, Ryosuke Niwa
no flags Details | Formatted Diff | Diff
Added sad comments (46.91 KB, patch)
2010-12-10 20:04 PST, Ryosuke Niwa
eric: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2010-12-08 19:54:03 PST
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.
Comment 1 Adam Roben (:aroben) 2010-12-09 10:03:45 PST
(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.
Comment 2 Adam Roben (:aroben) 2010-12-09 10:13:16 PST
<rdar://problem/8749946>
Comment 3 Brian Weinstein 2010-12-09 10:14:32 PST
(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?
Comment 4 Brian Weinstein 2010-12-09 11:28:15 PST
Landed failing expected results in r73632.
Comment 5 Ryosuke Niwa 2010-12-10 18:56:58 PST
Created attachment 76288 [details]
fixed the tests
Comment 6 Ryosuke Niwa 2010-12-10 19:33:02 PST
Comment on attachment 76288 [details]
fixed the tests

I lied this doesn't work :(
Comment 7 Ryosuke Niwa 2010-12-10 19:43:30 PST
(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.
Comment 8 Ryosuke Niwa 2010-12-10 19:50:44 PST
Created attachment 76290 [details]
adds a magic console.log
Comment 9 Ryosuke Niwa 2010-12-10 20:04:42 PST
Created attachment 76292 [details]
Added sad comments
Comment 10 Eric Seidel (no email) 2010-12-24 09:12:01 PST
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).