How To Test Drag and Drop Using Playwright

Have you ever watched a drag and drop test fail even though the UI looked perfectly stable?

I remember hitting this constantly when elements shifted a few pixels during animation or when the framework recalculated layout mid-drag.

Those tiny movements threw off the pointer path and made Playwright miss the exact location the component expected for a valid drop.

I eventually broke the interaction down across pointer alignment, movement timing, JavaScript handlers, and browser rendering differences, and that deeper analysis is how I finally found the solution.

Does Playwright Support Drag and Drop?

Yes. Playwright supports drag-and-drop interactions through its built-in dragTo() method. If your application uses standard HTML drag-and-drop behavior, this method simulates the sequence of pointer events the browser expects, including hovering, pressing the mouse button, moving the pointer, and releasing it.

That works well for most interfaces built on native browser drag-and-drop behavior.

Things become less predictable when an application uses custom JavaScript handlers, animated interactions, or frameworks that replace the native drag API. Components built with React, Vue, Angular, or libraries like SortableJS often rely on synthetic events and may expect specific pointer movements, offsets, or timing.

In those situations, I usually switch to manual mouse actions with mouse.down(), mouse.move(), and mouse.up(), or drag to precise coordinates instead of relying on dragTo(). This gives me finer control over the interaction and better matches what the application expects.

Try BrowserStack Now

Getting Started with the Built-in API

The first thing I do is check whether the application supports standard browser drag-and-drop behavior. If it does, Playwright’s dragTo() method is usually all you need. It simulates the sequence of pointer events a browser generates during a drag operation, making it a good starting point before trying more advanced techniques.

Using it is simple. Locate the element you want to move, locate the destination, and call dragTo() to perform the interaction.

Example:

from playwright.sync_api import sync_playwright


with sync_playwright() as pw:

    browser = pw.chromium.launch()

    page = browser.new_page()


    page.goto("https://app.example.com/board")


    source = page.locator(".item[data-index='1']")

    target = page.locator("#drop-zone")


    source.drag_to(target)


    # Verify the result

    # assert "Dropped" in target.text_content()


    browser.close()

Behind the scenes, Playwright moves the pointer to the source element, presses the mouse button, drags to the target, and releases it. If the application follows the browser’s native drag-and-drop behavior, this method is usually reliable.

If the interaction fails or behaves inconsistently, the application is likely using custom event handling or drag logic. In those cases, you’ll need more control over the pointer movement, which I’ll cover in the next section.

Using Manual Pointer Actions

Some applications implement dragging with custom JavaScript instead of the browser’s native drag-and-drop behavior. In these cases, dragTo() may not trigger the sequence of events the component expects.

Libraries such as SortableJS often calculate movement using pointer coordinates and intermediate mouse events. By controlling the mouse directly, I can reproduce the same interaction a real user performs.

I usually start by finding the center of both the source and target elements. Then I move the pointer in controlled steps, press the mouse button, drag to the destination, and release it. This gives me complete control over the movement, making it useful for interfaces that react to cursor position, animations, or transitions.

Example:

from playwright.sync_api import sync_playwright



with sync_playwright() as pw:

    browser = pw.chromium.launch()

    page = browser.new_page()



    page.goto("https://app.example.com/kanban")



    source = page.locator(".task-card")

    target = page.locator(".column-target")



    start = source.bounding_box()

    end = target.bounding_box()



    page.mouse.move(

        start["x"] + start["width"] / 2,

        start["y"] + start["height"] / 2

    )



    page.mouse.down()



    page.mouse.move(

        end["x"] + end["width"] / 2,

        end["y"] + end["height"] / 2,

        steps=15

    )



    page.mouse.up()



    browser.close()

Working with Custom Drag Behavior

Framework-based UIs rarely follow native drag behavior, so I see more inconsistencies when React, Vue, Angular, or libraries like SortableJS handle movement with custom logic.

These components often track pointer deltas, animation frames, or synthetic events that don’t fully align with Playwright’s built-in method. That’s why I adjust my approach based on how the framework interprets the gesture.

Here’s how I break down what the UI expects before choosing the right drag technique:

• Movement tracking: Frameworks that listen to every mousemove event respond better when I use multi-step pointer movement.
• Start-point sensitivity: Some libraries require the drag to begin from the element’s exact center or a specific handle.
• Threshold-based activation: Many components only enter “drag mode” after the pointer crosses a minimum distance.
• Synthetic event usage: Libraries like SortableJS rely on JavaScript-driven events, so manual mouse.down > mouse.move > mouse.up offers more control.

Next, I address cases where the UI lives inside iframes, shadow DOM, or nested structures, which affects how Playwright calculates pointer positions.

Working with Modern JavaScript Frameworks

JavaScript-driven drag and drop behaves differently from native HTML5 because the UI no longer listens to browser-generated events. The framework intercepts pointer movement, calculates positions in JavaScript, and updates the DOM with its own logic.

Playwright has to follow the same sequence the app expects, otherwise the drop handler never fires even though the UI visually moves.

These discrepancies usually appear when the drag logic is tied to internal state updates, debounce timers, or hit-testing rules that Playwright needs to replicate precisely.

Here is what the test must account for when JS controls the drag behavior:

• Event sequencing logic: Many libraries run dragstart > pointermove loop > dragend inside state machines, so skipping intermediate pointermove steps breaks the internal transition flow.
• Velocity-based movement: Some UIs calculate momentum or direction using timestamps between pointer moves, so instant jumps from point A to B cause the drop target check to fail.
• Collision detection rules: Libraries like interact.js or custom math-based systems compute overlap percentages, so the pointer must enter the target’s active region long enough for the collision resolver to register it.
• Reconciliation delays: React, Vue, and Angular re-render the ghost element on every pointermove using microtasks, so overly fast movements can outrun the UI’s repaint cycle.

Drag and Drop in iframes, Shadow DOM, and Nested DOMs

Drag and drop becomes harder when the draggable element and drop target don’t live in the same DOM tree. Playwright can still simulate the interaction reliably, but the test has to align with how the browser isolates frames and encapsulated DOM scopes. Most failures here come from incorrect context switching or from pointer events not propagating across boundaries.

To stabilise interactions across DOM boundaries, the test should consider:

• iframe context targeting: Use frame-locators because elements inside iframes require switching into the correct browsing context before drag movement is calculated.
• Shadow DOM encapsulation: Work with shadow locators so Playwright can resolve the element inside the shadow root and send pointer events directly into that scope.
• Nested DOM offset calculations: Ensure the pointer path accounts for the offset created by containers or transformed elements, since CSS transforms change coordinate space and break default hit-testing.
• Cross-boundary movement rules: Simulate gradual pointer movement because some frameworks block interactions when a pointer instantly jumps across DOM roots without crossing intermediate coordinates.

When Drag Tests Become Unreliable

I’ve noticed that many drag-and-drop tests that pass sometimes and fail other times are usually a sign that the application isn’t in the state your test expects. In most cases, the issue isn’t Playwright but the timing of the interaction or how the UI responds while the element is being dragged.

I’ve found that these issues become more common in applications with animations, sortable lists, or components that update while the pointer is moving. The key is to figure out when the interaction starts going wrong instead of adding random waits.

Here’s what I check first:

• Review the interaction step by step: Open the Playwright Trace Viewer and replay the test. Watching the pointer movement alongside screenshots usually shows whether the drag started correctly, reached the target, or ended too early.
• Wait for the UI, not the clock: If the application updates after the drag begins, wait for the state you expect instead of using fixed delays. This makes the test more reliable across different machines and CI environments.
• Check whether the page layout changes: Some applications move elements, expand containers, or reorder lists while dragging. If that happens, recalculate the element’s position before continuing instead of relying on coordinates captured earlier.
• Move the pointer more gradually: Some components only recognize a drag after receiving a series of movement events. Increasing the number of mouse.move() steps often produces a more realistic interaction than jumping directly to the destination.

Most flaky drag-and-drop tests can be traced back to one of these areas. Once you know where the interaction breaks down, the fix is usually much smaller than it first appears.

Why Run Drag-and-Drop Tests on BrowserStack?

A drag-and-drop test that passes locally doesn’t always behave the same way in production. Differences in browsers, operating systems, screen sizes, and input methods can affect how users interact with your application.

BrowserStack Automate helps you verify these interactions across real devices and browsers before they reach your users.

• Real Device Cloud: You can run drag-and-drop tests on physical phones, tablets, and desktops to verify that interactions behave consistently across different browsers, operating systems, and screen sizes.
• Real Device Features: Review interactions using actual touch input, orientation changes, animations, and other device capabilities that can influence how you perform drag-and-drop actions.
• Parallel Testing: Execute the same test suite across multiple browser and device combinations at the same time, making it easier for you to spot environment-specific failures without increasing execution time.
• Local Environment Testing: Test applications running on localhost or staging environments before deployment, so you can verify drag-and-drop workflows while features are still under development.
• Test Reporting & Analytics: Review screenshots, videos, logs, and test results to understand where an interaction failed and whether the issue is limited to a specific browser or device.

Talk to an Expert

Conclusion

Drag and drop appears straightforward, but consistent results depend on how pointer events, animations, and layout updates align. Playwright helps you model these movements accurately, handle JavaScript-driven logic, and stabilise interactions across complex DOM structures.

Running the same tests on BrowserStack confirms those interactions behave correctly on real devices and browsers. With real hardware, analytics, local testing, and parallel execution, BrowserStack exposes issues that never surface in desktop-only environments.

Try BrowserStack Now