v148 · web api · shipped
Correctly set dropEffect for dragEnter, dragLeave and dragOver events
A spec-compliance fix: Chrome 148 now sets the correct dataTransfer.dropEffect value on dragenter, dragleave, and dragover events. dragenter and dragover get the value derived from effectAllowed; dragleave always gets "none". Pages that read dropEffect in these handlers can now rely on the specified values.
at a glance
| What changed | Behaviour fix — no new APIs. dataTransfer.dropEffect now reflects the correct spec-defined value on three drag events. |
|---|---|
| Shipped in | Chrome 148 (desktop + Android) |
| ChromeStatus | 6325617459068928 — Correctly set "dropEffect" for dragEnter, dragLeave and dragOver events |
| Spec | HTML Living Standard — DataTransfer interface |
what changed and why
The HTML specification requires:
| Event | Spec-required dropEffect | Prior Chrome behaviour |
|---|---|---|
dragenter |
Derived from effectAllowed (e.g. "copy", "move") |
Often wrong or inconsistent |
dragover |
Derived from effectAllowed |
Often wrong or inconsistent |
dragleave |
Always "none" |
Not consistently "none" |
Drag-and-drop flows that read dropEffect on entry or hover to update a visual drop-target indicator could get unreliable values. Chrome 148 aligns with the spec so that cross-browser behaviour is now consistent.
example
dropZone.addEventListener('dragenter', (e) => {
// Chrome 148+: dropEffect is now set correctly based on effectAllowed
console.log(e.dataTransfer.dropEffect); // e.g. "copy" or "move"
dropZone.classList.add('active');
});
dropZone.addEventListener('dragleave', (e) => {
// Chrome 148+: dropEffect is always "none" on dragleave (per spec)
console.log(e.dataTransfer.dropEffect); // "none"
dropZone.classList.remove('active');
});