Bug 61319 - fast/events/selectstart-by-drag.html fails on Windows
Summary: fast/events/selectstart-by-drag.html fails on Windows
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: LayoutTestFailure, PlatformOnly
Depends on: 56347 19489
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-23 16:27 PDT by Ryosuke Niwa
Modified: 2011-05-24 15:29 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 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
Comment 1 Adam Roben (:aroben) 2011-05-24 05:01:46 PDT
Ryosuke checked in expected failure results in r87105 (thanks!).
Comment 2 Adam Roben (:aroben) 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.
Comment 3 Ryosuke Niwa 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.
Comment 4 Adam Roben (:aroben) 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.
Comment 5 Ryosuke Niwa 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?
Comment 6 Adam Roben (:aroben) 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.
Comment 7 Ryosuke Niwa 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.
Comment 8 Adam Roben (:aroben) 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.