Bug 61319
| Summary: | fast/events/selectstart-by-drag.html fails on Windows | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | HTML Editing | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | aroben, jberlin |
| Priority: | P2 | Keywords: | LayoutTestFailure, PlatformOnly |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 56347, 19489 | ||
| Bug Blocks: | |||
Ryosuke Niwa
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)
Ryosuke checked in expected failure results in r87105 (thanks!).
Adam Roben (:aroben)
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
(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)
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
(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)
(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
(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)
(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.