v148 · Drag & Drop · Interoperability
Correctly set "dropEffect" for "dragEnter", "dragLeave" and "dragOver" events
Chrome 148 fixes dataTransfer.dropEffect on drag events: dragenter and dragover now report the effective operation based on effectAllowed, and dragleave always reports "none" — as the spec requires.
concepts
-
DropEffect Live Viewer
Drag over different drop zones and watch
dataTransfer.dropEffectupdate in real time duringdragenter,dragover, anddragleave. See the new correct values Chrome 148 reports. -
Effective Drop Detection
A practical file-drop zone that reads
dropEffectduringdragenterto style the drop zone correctly — showing "copy", "move", or "none" based on actual effectAllowed — before the user releases. -
DropEffect Matrix
The complete
effectAllowed×dropEffectreference table showing what Chrome 148 now reports on each drag event. Drag the source card with anyeffectAllowedsetting and watch the live event log confirm spec-correct values. -
Dropzone Designer
Build multiple dropzones with different
effectAllowedanddropEffectsettings. Drag sources (copy / move / link / all / none) over zones to see cursor and negotiation change. A "Negotiation Trace" panel shows the Chrome 148 algorithm step-by-step. Tests the pre-148 child re-entry bug and shows a side-by-side pre/post Chrome 148 behaviour comparison. -
Before / After Comparison
Two drag zones side-by-side: the left simulates the pre-148 Chrome bug (dropEffect set arbitrarily — often "none" on dragenter, stale value on dragleave), the right shows Chrome 148's spec-correct values (dragenter/dragover compute from effectAllowed; dragleave is always "none"). Select any effectAllowed from a dropdown and drag over each zone to see the tables fill with contrasting values.
why it shipped
The HTML drag-and-drop spec defines how dataTransfer.dropEffect should be set on drag events: dragenter and dragover should compute a value from effectAllowed (e.g. if effectAllowed is "copy", the drop effect should be "copy"), and dragleave should always be "none". Before Chrome 148, these rules weren't followed — the value was set arbitrarily or carried over from previous events. This made it impossible to reliably read the drop operation before the drop occurred, breaking UI patterns like showing a "copy" icon on the cursor or styling a drop zone differently for move vs copy operations. Chrome 148 aligns with the spec and with Firefox, closing a long-standing interoperability gap.
references
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗