### Description
The inability to reliably block body scroll in Safari/Webkit an…d have a consistant scrolling experience across browsers on mobile devices is a very significant long-standing issue which greatly increases the difficulty of building advanced user interfaces and remains a significant compatibility issue between browsers.
This is a repeat of [last year’s interop request](https://github.com/web-platform-tests/interop/issues/84). Given that the majority of issues remain unresolved, we would like to re-raise it as a candidate for interop 2025.
The desired outcome for this focus area would be a set of tests that cover the behaviour, and to ensure that it works consistently across all the major browsers.
**Most important bug reports:**
[https://bugs.webkit.org/show\_bug.cgi?id=240859](https://bugs.webkit.org/show_bug.cgi?id=240859)
[https://bugs.webkit.org/show\_bug.cgi?id=240860](https://bugs.webkit.org/show_bug.cgi?id=240860)
[https://bugs.webkit.org/show\_bug.cgi?id=237961](https://bugs.webkit.org/show_bug.cgi?id=237961)
**Specification:**
[https://drafts.csswg.org/css-overflow/\#overflow-properties](https://drafts.csswg.org/css-overflow/#overflow-properties)
**Tests:**
None as yet (as far as we know)
# **Safari/WebKit \- Body Scroll Issues**
A Deep Dive into a Key Developer Pain Point:
1. Introduction
2. Use Cases
3. Technical Details
4. When and Why this Doesn’t Work
4.1. Incomplete Fix of the Initial Bug
4.2. “overflow: hidden” purposefully made ineffective in Safari iOS when the browser UI is collapsed
4.3. “overflow: hidden” purposefully made ineffective when the visual viewport is smaller than the layout viewport
5. How to fix: Summary
6. Conclusion
# **1\. Introduction**
For more than [8](https://bugs.webkit.org/show_bug.cgi?id=153852) years, one of the biggest issues Web Developers have had to deal with in Safari and other WebKit-based browsers on iOS (and in a lesser extent on macOS), is the inability to reliably block body scroll, or, said in other words, to remove the ability to scroll the current page in certain situations.
# **2\. Use Cases**
Such behaviour is needed in many situations where the user should not be able to scroll the page, whether on purpose, or by accident. It is essential when producing specific types of User Interfaces.
Specific examples of when it is needed include:
* when displaying temporarily any kind of overlay over the page: a popup, a centred dialog, a bottom sheet, a sidebar navigation, a top menu, an entire page on top of the page, etc.;
* for use cases where relying on page scroll is not possible, as more control over the scroll container is needed, and therefore element scroll containers need to be used instead;
* when implementing advanced gestures animations which should not trigger body scroll while occurring;
* when implementing high-fidelity drag and drop interfaces;
* when developing components that have their own scroll and zoom functionality (e.g. a map component or an E.R. Diagram Visualizer).
As you can see, there are plenty of use cases where such a feature is required. Yet, over the past 8 years, WebKit has not allowed developers to safely rely on it, as it has been broken in many ways. A search with the terms “*disable body scroll safari”* will reveal that a large number of developers have been grappling with this issue.
# **3\. Technical Details**
Blocking body scrolling is achieved by setting the value “hidden” to the CSS property “overflow” on the HTML element. Doing so should prevent further manual scrolling by the user, while maintaining the current scroll position, and still allowing programmatic scrolling.
This is per the “[CSS Overflow Module Level 3](https://drafts.csswg.org/css-overflow/#overflow-properties)” draft: “hidden: This value indicates that the box’s content is clipped to its padding box and that the UA must not provide any scrolling user interface to view the content outside the clipping region, nor allow scrolling by direct intervention of the user, such as dragging on a touch screen or using the scrolling wheel on a mouse.”
And had been validated by Simon Fraser from WebKit here: [w3c/csswg-drafts\#666 (comment)](https://github.com/w3c/csswg-drafts/issues/666#issuecomment-257889984)
The recently added “overflow” value “clip” should also prevent manual scrolling, as well as any programmatic scrolling. When setting back the value of “overflow” to “auto” or “scroll”, body scrolling should be re-enabled.
Although there were some initial concerns about making content overflowing the body inaccessible when this behaviour was introduced, the behaviour is now widely known, accepted and used by web authors in other browsers. It is all the more an issue since this works as intended in Firefox and all Chromium-based browsers since 2016, and has been an interoperability issue between them and Safari since then.
# **4\. When and Why this doesn’t Work**
Over the years, several bugs have prevented developers from disabling body scrolling. Some have been fixed, some haven’t and some new ones have appeared. The oldest WebKit issue related to this problem dates back to February 2016:
* [Bug 153852](https://bugs.webkit.org/show_bug.cgi?id=153852) (FIXED) \- with overflow:hidden CSS is scrollable on iOS
Many other issues related to this problem have been filed after that:
* [Bug 220908](https://bugs.webkit.org/show_bug.cgi?id=220908) (FIXED) \- with overflow:hidden CSS is scrollable on iOS standalone web app
* [Bug 214781](https://bugs.webkit.org/show_bug.cgi?id=214781) (DUPLICATE FIXED) \- Inconsistent scroll behavior when using overflow:hidden on body if added to home screen
* [Bug 222654](https://bugs.webkit.org/show_bug.cgi?id=222654) (NEW) \- Scrolling in home screen apps incorrectly latches to document
* [Bug 236561](https://bugs.webkit.org/show_bug.cgi?id=236561) (NEW) \- REGRESSION?: overflow:hidden on documentElement behaves inconsistently in iOS Safari 15.3.1
* [Bug 237961](https://bugs.webkit.org/show_bug.cgi?id=237961) (NEW) \- Standalone with viewport-fit cover causes overscroll issues, breaks position fixed and \-webkit-fill-available
* [Bug 240859](https://bugs.webkit.org/show_bug.cgi?id=240859) (NEW) \- \<body\> with overflow: hidden CSS is scrollable on iOS when Safari’s UI is collapsed
* [Bug 240860](https://bugs.webkit.org/show_bug.cgi?id=240860) (NEW) \- \<body\> with overflow: hidden CSS is scrollable when the visual viewport is smaller than the layout viewport
The situations where this works and where it doesn’t have changed several times over past WebKit/Safari versions, and these situations depend on multiple factors so it is hard to list them. However, the reasons why this doesn’t work properly have been outlined over time in the aforementioned WebKit issues. Problems are related to either:
* incomplete fix of the initial bug;
* “overflow: hidden” purposefully made ineffective in Safari iOS when the browser UI is collapsed ([bug 240859](https://bugs.webkit.org/show_bug.cgi?id=240859));
* “overflow: hidden” purposefully made ineffective when the visual viewport is smaller than the layout viewport ([bug 240860](https://bugs.webkit.org/show_bug.cgi?id=240860)).
In addition to these three reasons, bugs related to them make things even worse.
Let’s dig into each problem:
## **4.1. Incomplete fix of the initial bug**
Considering the fix to [Bug 153852](https://bugs.webkit.org/show_bug.cgi?id=153852), excluding the situations where the two other problems come in, body scroll should be prevented. However, as we can see with [Bug 237961](https://bugs.webkit.org/show_bug.cgi?id=237961) and [Bug 222654](https://bugs.webkit.org/show_bug.cgi?id=222654) in standalone mode on iOS (that is when a website is added to the homescreen), the fix doesn’t work.
[Bug 237961](https://bugs.webkit.org/show_bug.cgi?id=237961) seems to be fixed but has yet to be confirmed by WebKit. It’s worth noting that it is only “overscrolling” which seems to have issues here, and not actual scrolling. Still, it should not happen if “overflow: hidden” was working effectively.
## **4.2. “overflow: hidden” purposefully made ineffective in Safari iOS when the browser UI is collapsed**
This issue is covered by [bug 240859](https://bugs.webkit.org/show_bug.cgi?id=240859).
This exception concerns Safari on iOS and is the one causing the most problems as it is the most frequent situation for users to be in.
In Safari on iOS, the browser UI can be in two possible states: collapsed, or revealed. To go from collapsed to reveal, you can either scroll up, or tap on the collapsed UI. To go from revealed to collapsed, you can either scroll down, or go through Safari’s settings and use the option “Hide toolbar”. Note that in the latter case the only option to then reveal the UI is to tap on it.
In order to always allow the browser UI to be revealed by a scroll up (except when it has been collapsed through the “Hide toolbar option”), the decision has been made by the Safari team to not allow “overflow: hidden” to prevent body scrolling when the browser UI is collapsed. As mentioned by Simon Fraser in the initial bug report: *This is by design; scrolling is necessary to reveal the browser UI. This could be improved in future* ([bug 153852](https://bugs.webkit.org/show_bug.cgi?id=153852#c34)). (Note that “overflow: hidden” is also made ineffective as a consequence of this exception when the browser UI has been collapsed through the “Hide toolbar” option, although it then cannot be revealed by a scroll up.)
As mentioned in the WebKit issue another solution would allow Safari’s UI to collapse/reveal without interfering with body scrolling. Specifically, leaving Safari’s UI in its current state when “overflow: hidden” is set. If it is collapsed, let the user tap on it to expand it (as already possible).
## **4.3. “overflow: hidden” purposefully made ineffective when the visual viewport is smaller than the layout viewport**
This issue is covered by [bug 240860](https://bugs.webkit.org/show_bug.cgi?id=240860).
As indicated by Simon Fraser: *We allow scrolling when the visual viewport is smaller than the layout viewport (this is necessary to avoid getting locked in when zoomed), but we allow scrolling to the entire document. Ideally we'd only allow panning around in the layout viewport* ([bug 236561](https://bugs.webkit.org/show_bug.cgi?id=236561#c3)).
To our knowledge, this exception to the correct behaviour for “overflow: hidden” materialises in two situations:
* when a virtual keyboard is shown (on iOS);
* when the page is zoomed (on iOS and macOS).
In both these situations, making “overflow: hidden” ineffective to block body scrolling is not the correct behaviour.
The correct behaviour would be to stop making that exception, and indeed block body scrolling when the visual viewport is smaller than the layout viewport. Therefore, when a virtual keyboard is shown, no scrolling would be possible, as expected. However, as mentioned by Simon Fraser above and by [David Bokan](https://bugs.webkit.org/show_bug.cgi?id=236561#c3) [in the initial bug report](https://bugs.webkit.org/show_bug.cgi?id=153852#c11), if the page is zoomed, the user should be able to scroll around inside the area which would be visible if the page was not zoomed, without scrolling the page further.
Implementing this would not only help solve the body scroll blocking problem, it would also fix an interoperability issue, as both Firefox and all Chromium-based browsers behave that way, on all platforms (mobile and desktop).
# **5\. How to fix: summary**
To summarise, here is what needs to be done to fully fix the body scroll issue in Safari/WebKit:
* fix [bug 237961](https://bugs.webkit.org/show_bug.cgi?id=237961) and other specific bugs that could arise;
* remove the exception preventing body scroll blocking when Safari’s UI is collapsed (bug ([bug 240859](https://bugs.webkit.org/show_bug.cgi?id=240859));
* remove the exception preventing body scroll blocking when the visual viewport is smaller than the layout viewport and, only when the page is zoomed, implement scrolling inside the layout viewport clipped to its scroll position ([bug 240860](https://bugs.webkit.org/show_bug.cgi?id=240860));
* add tests that check if (over)scrolling is working correctly to identify any lingering issues and prevent future regressions.
# **6\. Conclusion**
This issue has been mentioned countless times by web developers as one of the major issues with Safari over the past 8 years. Fixing it would bring many benefits to web developers, web users and Safari. Specifically, it would eventually allow developers to drop heavy JavaScript libraries and build good user experiences for very common patterns, such as sidebars, dialogs, bottom sheets and many others.
### Specification
https://drafts.csswg.org/css-overflow/#overflow-properties
### Additional Signals
_No response_