v148 · Drag & Drop · Interoperability

Before / After Comparison

Chrome 148 fixes dataTransfer.dropEffect to match what the spec requires. The left column shows what Chrome reported before the fix (arbitrary / wrong values), the right column shows what Chrome 148 now reports (spec-correct values). Drag the source card over each drop zone to see the difference.

dropEffect value comparison
effectAllowed on source:
Before Chrome 148 — wrong values

Drag the card → dropEffect was set arbitrarily, often "none" on dragenter and carrying a stale value on dragleave.

Drag me (before)
Drop zone — watch the table
eventdropEffect (wrong)
Chrome 148 — correct values

Now: dragenter/dragover compute from effectAllowed; dragleave always "none".

Drag me (148)
Drop zone — watch the table
eventdropEffect (correct)
Select an effectAllowed value from the dropdown, then drag each card over its drop zone. The before column simulates the pre-148 bug (wrong dropEffect). The after column shows spec-correct values. Notice especially: dragleave is always "none" (after); dragenter reflects the actual effectAllowed (after).
// Chrome 148 fix: dropEffect is now spec-correct on all drag events // dragenter / dragover: compute from effectAllowed source.addEventListener('dragstart', e => { e.dataTransfer.effectAllowed = 'copy'; }); zone.addEventListener('dragenter', e => { // Before 148: e.dataTransfer.dropEffect was often "none" (wrong) // Chrome 148: e.dataTransfer.dropEffect === "copy" (correct, from effectAllowed) if (e.dataTransfer.dropEffect !== 'none') { zone.classList.add('drop-target-active'); } }); zone.addEventListener('dragleave', e => { // Before 148: could carry a stale non-"none" value // Chrome 148: always "none" on dragleave (spec-correct) zone.classList.remove('drop-target-active'); });

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗