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

  1. DropEffect Live Viewer

    Drag over different drop zones and watch dataTransfer.dropEffect update in real time during dragenter, dragover, and dragleave. See the new correct values Chrome 148 reports.

    Live API Drag & Drop
  2. Effective Drop Detection

    A practical file-drop zone that reads dropEffect during dragenter to style the drop zone correctly — showing "copy", "move", or "none" based on actual effectAllowed — before the user releases.

    Interactive UX Pattern
  3. DropEffect Matrix

    The complete effectAllowed × dropEffect reference table showing what Chrome 148 now reports on each drag event. Drag the source card with any effectAllowed setting and watch the live event log confirm spec-correct values.

  4. Dropzone Designer

    Build multiple dropzones with different effectAllowed and dropEffect settings. 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.

  5. 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 ↗