NEW 61319
fast/events/selectstart-by-drag.html fails on Windows 
https://bugs.webkit.org/show_bug.cgi?id=61319
Summary fast/events/selectstart-by-drag.html fails on Windows
Ryosuke Niwa
Reported 2011-05-23 16:27:41 PDT
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
Attachments
Add attachment proposed patch, testcase, etc.
Adam Roben (:aroben)
Comment 1 2011-05-24 05:01:46 PDT
Ryosuke checked in expected failure results in r87105 (thanks!).
Adam Roben (:aroben)
Comment 2 2011-05-24 05:02:23 PDT
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.
Ryosuke Niwa
Comment 3 2011-05-24 09:31:53 PDT
(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.
Adam Roben (:aroben)
Comment 4 2011-05-24 09:44:55 PDT
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.
Ryosuke Niwa
Comment 5 2011-05-24 09:49:31 PDT
(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?
Adam Roben (:aroben)
Comment 6 2011-05-24 09:53:46 PDT
(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.
Ryosuke Niwa
Comment 7 2011-05-24 09:57:28 PDT
(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.
Adam Roben (:aroben)
Comment 8 2011-05-24 10:03:42 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.