Skip to content

Fix window title bar pushed off-screen during top-edge resize (#399) - #402

Merged
AllTerrainDeveloper merged 3 commits into
WordPress:trunkfrom
alshakerM:fix/window-resize-bounds-399
Jul 23, 2026
Merged

Fix window title bar pushed off-screen during top-edge resize (#399)#402
AllTerrainDeveloper merged 3 commits into
WordPress:trunkfrom
alshakerM:fix/window-resize-bounds-399

Conversation

@alshakerM

@alshakerM alshakerM commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Issue: 399

Hi @CookieDarb I was using the desktop mode and ran into this issue, funny enough you already created the issue, it's only fair I fix it 😄

When resizing a window using the upper handles (nw or ne), the window could be extended beyond the upper boundary of the desktop viewport, pushing the title bar off-screen and leaving the window stuck in an inaccessible state.

Before

Screen.Recording.2026-07-23.at.8.25.13.PM.mov

After

Screen.Recording.2026-07-23.at.20.03.40.mov

This fix adds bounds checking to the onResizeMove handler that mirrors the existing drag handler pattern. The window position is now constrained to the desktop bounds, preventing:

  • Top-edge resizing (nw, ne) from pushing y below EDGE_MARGIN
  • Left-edge resizing (nw, sw) from pushing x below EDGE_MARGIN
  • Right/bottom edges from extending beyond desktop bounds

The computeResize() function remains pure math with no bounds awareness, keeping the separation of concerns clean.

alshakerM and others added 3 commits July 23, 2026 19:40
…ess#399)

When resizing a window using the upper handles (nw or ne), the window
could be extended beyond the upper boundary of the desktop viewport,
pushing the title bar off-screen and leaving the window stuck in an
inaccessible state.

This fix adds bounds checking to the onResizeMove handler that mirrors
the existing drag handler pattern. The window position is now constrained
to the desktop bounds, preventing:
- Top-edge resizing (nw, ne) from pushing y below EDGE_MARGIN
- Left-edge resizing (nw, sw) from pushing x below EDGE_MARGIN
- Right/bottom edges from extending beyond desktop bounds

The computeResize() function remains pure math with no bounds awareness,
keeping the separation of concerns clean.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@AllTerrainDeveloper

Copy link
Copy Markdown
Collaborator

Hey! Thank you very much, this has fixed that particular issue, the PR is still valid, but I'll create a new issue with the following behaviour that needs to be fixed too:

bounds.mov

@AllTerrainDeveloper AllTerrainDeveloper left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thank you!

@AllTerrainDeveloper
AllTerrainDeveloper merged commit 12c2f7f into WordPress:trunk Jul 23, 2026
6 checks passed
@AllTerrainDeveloper

Copy link
Copy Markdown
Collaborator

@alshakerM and welcome!

image

https://next-admin.blog/contribute/

AllTerrainDeveloper added a commit to CookieDarb/desktop-mode that referenced this pull request Jul 23, 2026
Trunk picked up two fixes for the same bug (WordPress#399): WordPress#402 clamped the
window position in onResizeMove after the math ran, and this PR clamps
inside computeResize while shrinking the dimension by the clamped
difference. The handler-side clamp is strictly worse once both exist:
clamping y without compensating height lets the pinned bottom edge
slide down while the user drags the top handle, and its Math.min
against the desktop's right/bottom shifts the whole window during a
plain SE grow — stricter than what drag itself enforces. Keep the
pure-math clamp (which the vitest suite covers directly) and remove
the handler block.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WCknM6zk6JS14pdLUiqdRR
AllTerrainDeveloper added a commit that referenced this pull request Jul 23, 2026
* fix: enforce viewport boundaries during window resize

* Drop the handler-side resize clamp in favor of the computeResize one

Trunk picked up two fixes for the same bug (#399): #402 clamped the
window position in onResizeMove after the math ran, and this PR clamps
inside computeResize while shrinking the dimension by the clamped
difference. The handler-side clamp is strictly worse once both exist:
clamping y without compensating height lets the pinned bottom edge
slide down while the user drags the top handle, and its Math.min
against the desktop's right/bottom shifts the whole window during a
plain SE grow — stricter than what drag itself enforces. Keep the
pure-math clamp (which the vitest suite covers directly) and remove
the handler block.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WCknM6zk6JS14pdLUiqdRR

---------

Co-authored-by: prismiwi2015 <daniel.lopez@automattic.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants