Dashboard Widgets not draggable

[Presskopp]

The issue is a bit hard to explain, please watch the video. Sometimes it's impossible to drag a widget to the desired space, sometimes the 'drop zone' has the size of the dragged widget, sometimes not, etc.

[audrasjb]

Thanks for the ticket, I'm moving it to 7.0 as it looks like a regression with the admin reskin.

[ozgursar]

Widget drag drop

[ozgursar]

Reproduction Report

Environment

• WordPress: 7.1-alpha-62284
• PHP: 8.3.30
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Opera
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Randomly drag and drop widgets on admin dashboard
2. Observe that if the drag requires scroll, widget may not be dropped to the desired position
3. 🐞 Bug occurs

Expected behavior

• Even the browser height is not enough, scrolling should not affect drag behavior.

Additional Notes

• I found that if the browser height is enough, widget can be dropped easily. If the drag involves scrolling at the same time, widget (probably depending on its own height) may not be dragged if its new position is below certain level.

Screenshots/Screencast with results

https://core.trac.wordpress.org/attachment/ticket/65151/widget-drag-issue.mp4

[gaurangsondagar]

Admin Dashboard Widgets Drag issue

[gaurangsondagar]

Reproduction Report: https://core.trac.wordpress.org/ticket/65151

Environment:

• PHP: 8.2.29
• WordPress: 7.0-RC2-62242
• Web server: Apache
• Database: MySQL
• Browser: Chrome
• OS: Ubuntu 22.04.5 LTS

Steps I followed:

• Performed random drag-and-drop actions with widgets on the admin dashboard
• Noticed that when scrolling is required during dragging, the widget does not always drop in the intended location
• The issue was successfully reproduced

Result:
The drag issue was successfully reproduced, please review the following video attachment as a reference.

https://core.trac.wordpress.org/attachment/ticket/65151/admin-dashboard-widgets-drag-issue.mp4

[huzaifaalmesbah]

Hello @gaurangsondagar Just to clarify, no patch has been submitted for this ticket so far.

The report you shared appears to be a Reproduction Report, showing how the issue occurs, rather than a patch test.

Thanks for providing report.

[gaurangsondagar]

Hi @huzaifaalmesbah Thanks for correcting me. I have updated my reproduce report.

[rafaeldella]

Hello @yusufmudagal ,
I tested this on my local environment (running WordPress 7.0-alpha/trunk) and was unable to reproduce the issue. In my case, the Dashboard widgets are draggable and behave as expected across all columns.
You can see the screen recording of my test here: ​https://vimeo.com/1188861508/e37502ff31

Environment details:

• OS: Windows 10 (WSL2)
• Browser: Chrome
• Local Setup: wp-env / Docker

[siliconforks]

Replying to rafaeldella:

I tested this on my local environment (running WordPress 7.0-alpha/trunk) and was unable to reproduce the issue. In my case, the Dashboard widgets are draggable and behave as expected across all columns.
You can see the screen recording of my test here: ​https://vimeo.com/1188861508/e37502ff31

That looks like version 6.9.4.

[siliconforks]

I noticed that removing overflow: hidden from the #dashboard-widgets-wrap element seems to make the drag and drop a lot less glitchy. Anyone have any thoughts on whether it is safe to remove this?

[jorbin]

Tested using playground and Chrome on macOS and each of the oddities with drag and drop that I see is also present in 6.9, so I'm not sure if this is a regression in 7.0.

[audrasjb]

After testing on 6.9, I concur with @jorbin: this was also an issue previously. Let's move it to 7.1 as it is not a critical issue.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[priyanshuhaldar]

The drop area for each column does not extend to the full page height — it is limited to the height of the widgets currently present in that column. This means dragging a widget to the correct X axis (i.e. visually above the target column) is not enough; the widget must also be dragged within the vertical bounds of the existing widgets in that column for the drop to register. Any attempt to drop below the last widget in a column silently fails, making it appear as though certain positions are not droppable at all.

Would it be appropriate to extend the drop area to the full page height? This would allow widgets to be dropped anywhere along the column's vertical space, making the interaction more intuitive. Any thoughts or inputs on this approach would be greatly appreciated.

### Description

This PR resolves the glitchy drag-and-drop behavior encountered when rearranging widgets on the WordPress admin dashboard. Specifically, it fixes the layout calculations, visibility degradation, and viewport clipping that occur when dragging widgets across uneven columns or when the action requires page scrolling.

## Problems Addressed

1. Drop indicator missing past the end of a short column: The placeholder only appears where the dragged widget overlaps a .meta-box-sortables drop area. Because each column is only as tall as its own widgets, dragging a widget toward a shorter column (or below its last widget) left no droppable region, so no placeholder appeared even though the drop itself worked.
2. Placeholder hard to see / inconsistently styled: The placeholder rule used :not(.empty-container .sortable-placeholder) — a :not() containing a descendant combinator. In engines without full Selectors Level 4 :not() support, the entire rule is dropped, leaving the placeholder unstyled (an invisible gap). Even when applied, it was a faint 1px light-grey outline with no fill.
3. Helper/placeholder clipped while scroll-dragging: #dashboard-widgets-wrap used overflow: hidden (only to contain floated columns), which clipped the absolutely-positioned sortable helper when it left the wrap bounds during scroll-drags, and could be picked up as the drag scrollParent, skewing placeholder position math.
4. Empty-column hint floated to mid-column: The "Drag boxes here" text was vertically centered (top: 50%) inside a full-height empty column, pushing it far down the page.

## Changes

• src/js/_enqueues/admin/postbox.js — On drag start, equalize all Dashboard .meta-box-sortables drop areas to the tallest column's height (cleared on stop), so a widget can be dropped anywhere in any column. refreshPositions() (already called in start) re-caches the new heights for jQuery UI's intersection checks. Scoped to #dashboard-widgets so the post-edit screen is unaffected.
• src/wp-admin/css/common.css — Made the .sortable-placeholder reliably visible (2px dashed theme color + subtle fill) and split the empty-container exception into its own simple rule instead of a fragile :not() with a descendant combinator, so the placeholder styles can't be silently dropped.
• src/wp-admin/css/dashboard.css — Replaced overflow: hidden on #dashboard-widgets-wrap with display: flow-root (contains the floated columns without clipping the drag helper), and top-aligned the empty-column "Drag boxes here" hint instead of vertically centering it.

Trac ticket: https://core.trac.wordpress.org/ticket/65151

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.8
Used for: Diagnosing the root causes and drafting the CSS/JS changes. All changes were reviewed, tested in a local develop build, and edited by me.

[kabir93]

I found the issue too and created a PR after fixing this.

​https://www.loom.com/share/3a5fbd886623498d9a6a8735d4069105

[mgwn]

Reproduction Report

Environment

• WordPress: 7.0
• Subdirectory: No
• PHP: 8.3.31
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 148.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.3.0

Steps taken

1. Drag all widgets into one column so the page height exceeds the viewport and scrolling is possible
2. Drag one widget into a different column
3. Drag the widget back to the column with all of the widgets meanwhile scrolling or positioning the cursor at the bottom of the viewport so the browser scrolls automatically
4. The widget gets stuck within the first (above the fold) viewport
5. The widget height plays a role - taller widgets make the bug worse

Expected behavior

• The widget should follow the cursor position - the cursor should be the indicator of where the widget can be dropped.

Screencast with results

​https://jam.dev/c/6fbbc7db-ce9c-4633-9e4e-32f2f9dca676