A scrollable panel inside a modal keeps scrolling the page behind it once it reaches its own end. Which CSS property stops that, and how do its values differ?

## What scroll chaining is When you scroll inside a nested scroll container and it runs out of scrollable area, browsers do not stop — they hand the leftover delta to the next scroll container up the ancestor chain, and ultimately to the viewport. That handoff is *scroll chaining*, and it is the correct default for ordinary nested content: a user flicking through a page should not get stuck because their pointer happened to be over a small scrollable box. It is exactly wrong for overlays. A dialog, drawer, or dropdown is conceptually a separate surface floating above the page. When the user scrolls to the bottom of its content and the page behind starts moving, the illusion breaks and the page's scroll position is lost — a bug users experience as "the background jumped". ## The property ```css .modal-body { overflow-y: auto; overscroll-behavior: contain; } ``` `overscroll-behavior` is a shorthand for `overscroll-behavior-x` and `overscroll-behavior-y`; logical longhands `overscroll-behavior-inline` and `overscroll-behavior-block` also exist. Its values: - **`auto`** — the initial value. Scrolls chain normally to ancestors. - **`contain`** — no chaining past this element. The local overscroll affordance is preserved: on touch platforms the user still gets the rubber-band or glow that says "you have reached the end". - **`none`** — no chaining, and the local overscroll affordance is suppressed as well. Nothing bounces, nothing glows. For an overlay, `contain` is nearly always the right choice: it fixes the leak while keeping the feedback that tells the user the surface has ended. `none` is for cases where the affordance itself is the problem — most commonly disabling pull-to-refresh on a page whose top area has its own gesture, by setting `overscroll-behavior-y: none` on the page's own scroll container. ## The trap: it only applies to scroll containers The declaration does nothing on a box that is not a scroll container. A modal whose body happens to be short — nothing to scroll — will still let a touch drag or wheel gesture move the page behind it, because there is no local scroll for the chain to start from. This is why `overscroll-behavior` alone is not a complete modal scroll lock; it fixes the *chaining* case, not the *no local scroll* case. A robust overlay therefore usually combines two things: `overscroll-behavior: contain` on the scrollable region, and a page-level scroll lock while the overlay is open. The usual page-level lock is `overflow: hidden` on the page's own scroll container — noting that the page then still holds its scroll offset, so the position must be preserved and restored rather than left to chance. Where the platform supports a top-layer overlay mechanism, some of this is handled for you and less manual locking is required. ## Related but different It is worth separating three things people conflate: - **`overscroll-behavior`** — where a scroll goes when a container reaches its end. A layering rule. - **`overflow`** — whether a box clips and scrolls at all. A containment rule. - **`scroll-behavior: smooth`** — how a *programmatic* or fragment-triggered scroll animates. Nothing to do with chaining, and pairing it with `prefers-reduced-motion` is the accessible practice. ## Applying it well - Put `overscroll-behavior: contain` on every overlay scroll region as a matter of course; the cost is nil and it removes a whole class of bug reports. - Prefer `contain` to `none` unless you have a specific reason to remove overscroll feedback — the feedback is a real usability signal on touch devices. - Be axis-specific when only one direction is a problem: `overscroll-behavior-y: contain` on a vertically scrolling drawer leaves horizontal behaviour untouched. - Remember it is only meaningful on a scroll container. Applying it to a static wrapper is a no-op that reads like a fix in review and is not one. - Long lists inside overlays benefit twice: chaining containment plus the fact that the overlay's own scroll no longer competes with the page's. ## Support Chrome and Firefox shipped `overscroll-behavior` years ago; Safari added it in version 16 in 2022, so it is available across all major engines today. Older code often works around its absence with script that cancels the gesture, which is worth deleting when you find it.