Bug 30107 - [Mac] dropEffect is incorrect when effectAllowed = "none"
Summary: [Mac] dropEffect is incorrect when effectAllowed = "none"
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh All
: P2 Normal
Assignee: Daniel Bates
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-05 21:41 PDT by Daniel Bates
Modified: 2009-10-06 12:15 PDT (History)
3 users (show)

See Also:


Attachments
Patch (1.66 KB, patch)
2009-10-05 21:44 PDT, Daniel Bates
eric: review+
eric: commit-queue-
Details | Formatted Diff | Diff
Test case (11.83 KB, text/html)
2009-10-05 21:56 PDT, Daniel Bates
no flags Details
Patch with test case (9.98 KB, patch)
2009-10-06 12:07 PDT, Daniel Bates
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2009-10-05 21:41:40 PDT
The Mac build of WebKit does not comply with the HTML 5 specification for drag-and-drop with respect to the case when effectAllowed == "none" (*).

Currently, the resulting drop effect in the Mac build is determined by the followings mapping when effectAllowed == "none":


dropEffect:		Actual drop effect:	Expected drop effect:
"none"     -----------> "none"			"none"
"copy"     -----------> "copy"			"none"
"move"     -----------> "move"			"none"
"link"     -----------> "none"			"none"
"dummy"    -----------> "none"			"none"


As per section 7.9.2 of the HTML 5 specification <http://dev.w3.org/html5/spec/Overview.html#the-dragevent-and-datatransfer-interfaces>, regardless of the specified dropEffect, when effectAllowed == "none" the resulting dropEffect should be "none".

(*) It also does not comply with the spec. when effectAllowed == "uninitialized", but we should resolve this in a separate bug (after fixing bug #24731) so that we can bring HTML 5 compliance to both Mac and Windows builds in a platform-independent way.
Comment 1 Daniel Bates 2009-10-05 21:44:22 PDT
Created attachment 40685 [details]
Patch

No test case is included in this patch because it uses the same test case as in the patch for bug #24731.
Comment 2 Daniel Bates 2009-10-05 21:56:49 PDT
Created attachment 40686 [details]
Test case

Here is a test case based off of the test case in the patch for bug #24731. Compare the results under Safari and Firefox.
Comment 3 Eric Seidel (no email) 2009-10-06 09:48:59 PDT
Comment on attachment 40685 [details]
Patch

You should still mention which test case this fixes.  If bug 24731 hasn't yet landed, you might consider landing the test with this change and skipping it on windows for now until bug 24731 can be fixed.
Comment 4 Eric Seidel (no email) 2009-10-06 09:49:13 PDT
Comment on attachment 40685 [details]
Patch

cq- due to my comment above.
Comment 5 Daniel Bates 2009-10-06 10:33:49 PDT
Before I'll land this patch, I'll add this test case to it and modify the file LayoutTest/platform/win/Skipped to skip this test.

(In reply to comment #3)
> (From update of attachment 40685 [details])
> You should still mention which test case this fixes.  If bug 24731 hasn't yet
> landed, you might consider landing the test with this change and skipping it on
> windows for now until bug 24731 can be fixed.
Comment 6 Daniel Bates 2009-10-06 12:07:10 PDT
Created attachment 40735 [details]
Patch with test case

Patch with test case.
Comment 7 Daniel Bates 2009-10-06 12:15:00 PDT
Committed r49203: <http://trac.webkit.org/changeset/49203>