ID:BUG-044Status:in-progress
After a drawer has been opened, the sticky site header trails behind page scrolling on iOS Safari
Severity:majorSource:SPEC-060
Criteria completion
Tracking started Oct 22 — check back for trends.
Relationships
Implements 1
Branches 2
History 1
fccc38bCreated (in-progress)
Steps to Reproduce
- On iOS Safari, open a page whose default layout has the sticky
.rf-header(for example a release page under/releases/). - Open a drawer through a
{% ref preview="drawer" %}link, then close it. - Scroll the page.
Expected
The header stays pinned to the top of the viewport, as it does before any drawer is opened.
Actual
The header trails behind the scroll and catches up once scrolling settles, as though it were animated. It begins only after a drawer has been opened, and it lasts until the page is reloaded.
Environment
- Mobile Safari (reported on iOS, possibly other browsers too); not reproducible in headless Chromium
@refrakt-md/skeleton0.41.1,@refrakt-md/behaviors0.41.1
Cause
The drawer's scroll lock (packages/skeleton/styles/runes/drawer.css) set overflow: hidden on both html and body while a drawer was open. With both locked, body becomes a scroll container of its own. Toggling that is a long-standing WebKit trigger for sticky and fixed elements to be repositioned on the main thread rather than with the compositor's scroll, so they trail behind it. Locking the root alone is enough to stop the page scrolling under the modal: iOS Safari has honoured overflow: hidden on html since iOS 16.
Acceptance Criteria
- The scroll lock sets
overflow: hiddenonhtmlonly, not onbody - Scrolling inside an open drawer's body does not chain to the page (
overscroll-behavior: contain) - On iOS Safari, the sticky header stays pinned while scrolling after a drawer has been opened and closed