Skip to content

Fix/scroll lock propagation target - #29

Merged
porksteak merged 2 commits into
masterfrom
fix/scroll-lock-propagation-target
Aug 18, 2026
Merged

porksteak merged 2 commits into
masterfrom
fix/scroll-lock-propagation-target

Conversation

@porksteak

Copy link
Copy Markdown
Collaborator

No description provided.

porksteak and others added 2 commits August 18, 2026 11:31
The viewport reads its overflow from the root element, unless that
computes to `visible`, in which case the value comes from <body>. Writing
the lock onto <html> therefore switched the propagation source on any page
that styles <body>, and <body> — which usually also has `height: 100%` —
became a scroll container in its own right. The viewport's scrollable area
collapsed to one screen, the browser clamped the offset to zero, and the
page jumped to the top and stayed there after the dialog closed.

The lock now lands on whichever element the viewport is already listening
to, so nothing changes about which box scrolls. The scrollbar gutter stays
on the root element, where it belongs either way.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@porksteak
porksteak merged commit 37e3f68 into master Aug 18, 2026
2 checks passed
@porksteak
porksteak deleted the fix/scroll-lock-propagation-target branch August 18, 2026 04:12
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.

1 participant