61319 2011-05-23 16:27:41 -0700 fast/events/selectstart-by-drag.html fails on Windows 2011-05-24 15:29:52 -0700 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) Unspecified Unspecified NEW LayoutTestFailure, PlatformOnly P2 Normal --- 56347 19489 1 rniwa webkit-unassigned aroben jberlin oldest_to_newest 408452 0 rniwa 2011-05-23 16:27:41 -0700 fast/events/selectstart-by-drag.html has been failing on Windows ever since it was checked in: Initial state: PASS -Mouse down: PASS -Moving slightly to the right: PASS -Moving slightly to the left: PASS +Mouse down: FAIL - expected selection to be caret but was range +Moving slightly to the right: FAIL - expected selection to be caret but was range +Moving slightly to the left: FAIL - expected selection to be caret but was range Moving to the right: PASS Moving further to the right: PASS -Moving back to the left: PASS +Moving back to the left: FAIL - expected selection to be caret but was range Moving to the right again: PASS Mouse down on the right: PASS Moving to the left: PASS 408777 1 aroben 2011-05-24 05:01:46 -0700 Ryosuke checked in expected failure results in r87105 (thanks!). 408778 2 aroben 2011-05-24 05:02:23 -0700 Ryosuke, do you think this represents a bug in WebKit, or just a bug in the test or test harness? If the latter, we should move this bug to the Tools/Tests component. 408922 3 rniwa 2011-05-24 09:31:53 -0700 (In reply to comment #2) > Ryosuke, do you think this represents a bug in WebKit, or just a bug in the test or test harness? If the latter, we should move this bug to the Tools/Tests component. It's hard to tell. It's very odd that the first click on a page creates a range selection though. There might be a bug in Windows port or Windows port's DRT because Chromium Windows passed the test. 408931 4 aroben 2011-05-24 09:44:55 -0700 Maybe a click from a previous test is causing the click in this test to be counted as a double-click? We've seen that before. See bug 56347. 408934 5 rniwa 2011-05-24 09:49:31 -0700 (In reply to comment #4) > Maybe a click from a previous test is causing the click in this test to be counted as a double-click? We've seen that before. See bug 56347. That is an annoying bug. But I'm confused as to how that happens. m_clickCount is stored in EventHandler but that class exists per frame. If we're loading a new page, we'll surely create a new frame, right? 408936 6 aroben 2011-05-24 09:53:46 -0700 (In reply to comment #5) > (In reply to comment #4) > > Maybe a click from a previous test is causing the click in this test to be counted as a double-click? We've seen that before. See bug 56347. > > That is an annoying bug. But I'm confused as to how that happens. m_clickCount is stored in EventHandler but that class exists per frame. If we're loading a new page, we'll surely create a new frame, right? EventHandler::m_clickCount is set based on the PlatformMouseEvent that's passed in. The PlatformMouseEvent has a click count of 2 (or more) due to WebKit not clearing its global click count on navigation. 408939 7 rniwa 2011-05-24 09:57:28 -0700 (In reply to comment #6) > EventHandler::m_clickCount is set based on the PlatformMouseEvent that's passed in. The PlatformMouseEvent has a click count of 2 (or more) due to WebKit not clearing its global click count on navigation. Where is this global counter stored? It seems like we should just fix that. 408945 8 aroben 2011-05-24 10:03:42 -0700 (In reply to comment #7) > (In reply to comment #6) > > EventHandler::m_clickCount is set based on the PlatformMouseEvent that's passed in. The PlatformMouseEvent has a click count of 2 (or more) due to WebKit not clearing its global click count on navigation. > > Where is this global counter stored? It seems like we should just fix that. I'll put the info in bug 56347.