| Summary: | dropEffect not set to correct default values in dragenter / dragover | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel Cheng <dcheng> | ||||||||||||||||||||
| Component: | UI Events | Assignee: | Nobody <webkit-unassigned> | ||||||||||||||||||||
| Status: | NEW --- | ||||||||||||||||||||||
| Severity: | Normal | CC: | bweinstein, danya.postfactum, dbates, dtrebbien, eric, ian, oliver, rniwa, tony, webkit | ||||||||||||||||||||
| Priority: | P2 | ||||||||||||||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||
| URL: | http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dropEffect-initialization | ||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||
| Bug Blocks: | 79171 | ||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Daniel Cheng
2010-04-01 22:46:27 PDT
Created attachment 52380 [details]
Testcase
Created attachment 52381 [details]
Patch
Created attachment 52383 [details]
Patch
Created attachment 52384 [details]
Patch
Created attachment 52399 [details]
Patch
Created attachment 52506 [details]
Patch
Adding bweinstein who I think originally set these values in http://trac.webkit.org/changeset/53287 Created attachment 52580 [details]
Patch
Fix incorrect initialization, remove unnecessary contentEditable handling.
Can you please compare the test results with that produced by mozilla? Firefox's behavior differs slightly from the spec: From DOM-initiated drags, if effectAllowed is "all", "copyMove", "linkMove", or "uninitialized", the default dropEffect is "move". Firefox doesn't seem to set effectAllowed to "uninitialized" for drags from text boxes. When dragging links, effectAllowed is set to "uninitialized" but default dropEffect is set to "move". From IRC: < dcheng> olliej: just curious if you're interested in reviewing https://bugs.webkit.org/show_bug.cgi?id=37012 since you commented on it a few days ago. < olliej> dcheng: does the new behaviour match ie? < olliej> dcheng: matching the spec comes secondary to matching what implementations do -- the spec for dnd is mostly an attempt to reverse engineer what browser already did < dcheng> I'll check. Results can be found at http://spreadsheets.google.com/pub?key=tPZ1c0LEi4RBJ2CG4jV13Fw&output=html What's the proper approach here? If you don't mind, I'll update the patch to follow IE behavior and email whatwg@ for clarification on why the spec differs from IE in that respect. Created attachment 53910 [details]
Expanded test page
Updated the page with information for Firefox and Safari. I also found some interesting issues that seem to be specific to Safari. Created attachment 53997 [details]
drag/drop testcase
Ian, can you comment on the specced behavior for dropEffect? It seems what's currently specced doesn't match any browser, assuming dcheng's testing was correct of course. Was that intentional? I looked, but couldn't find any relevant discussion on whatwg@ about dropEffect. dcheng, maybe it's worth writing an email to whatwg@ with your data? Comment on attachment 52580 [details]
Patch
It looks like this change is blocked on interacting with the whatwg. Ideally, we'd get the spec updated to the desired behavior and the change all the implementations to match. Feel free to re-nominate for review (or to post a new patch) once we've got the spec onboard.
What is the current status of this bug report ? On reviewing this case, it appears that if the value of datatransfer.effectAllowed is set in dragstart, it is supposed to be retained during the drag, but it's being reset to "all" sometime before the dragenter event. This means that drag sources can't specify that they only allow copying, moving or linking from their data. You may need to solve both of these to actually "fix" this bug. |