In 2026, after an H5 modal closes the page jumps back to the top and long-list users lose their scroll position—is it because scroll locking wasn't restored?

Conclusion: After a modal closes and the page jumps back to the top, it is usually not a wrong scroll lock but a lock without restoration. When using position:fixed to lock the background, the page has already detached from its original scroll position; if the recorded scrollTop is not written back on close, users go from the eighth screen back to the first. In 2026 mobile delivery, locking and restoration should be accepted as a pair of actions.

After the modal closes and the page jumps back to the top, which layer's position is lost?

Scroll-through and position loss often appear together, but root causes differ: scroll-through is when gestures are not intercepted, while position loss is when the locking method changes document flow. When both use the same overflow:hidden trick, the result can be that the background no longer scrolls and the position is gone after close.

• Locking body with fixed: The container detaches from document flow, page height collapses to 0, and on close the browser reflows to the new height, so the position naturally returns to the top.
• Locking only the overflow of html or body: Position is usually not lost, but it does not cleanly intercept iOS inertia and inner scroll containers.
• Locking an inner scroll container: Position is generally preserved, provided that the container's scrollTop is restored on close rather than reset.
• When the iOS keyboard is involved: Focus scrolling changes the visual viewport, and after the keyboard is dismissed the page may stop at an offset position, looking both like a jump to top and like drift.

The test is direct: open the modal, scroll to the bottom of the list, close it, and see whether the page behind it stays where it was. Test once with a long-list modal and once with an input modal; only when both pass is the fix complete.

Delivery scene: a campaign page with a two-day schedule—where does rework add time?

A common constraint is a budget and timeline compressed to two or three days to finish an H5 campaign page, with assets and APIs in place, and the modal directly using position:fixed plus overflow:hidden. On the day it enters testing, an operations person scrolled to the eighth screen of the product list on iOS, opened the filter, and after closing it the page returned to the first screen, forcing them to scroll through 60-plus products again. The rework is not rewriting logic but adding scrollTop recording and restoration, then regressing three pages with long lists. By experience range, this costs roughly an extra half day to a day; if that half day collides with the test-entry day, it often eats into the evening.

In the retrospective, the time-saving move was not writing fewer lines but treating “lock—restore” as one action from the start. The team later merged these two steps into the modal integration checklist, testing real-device scrolling and close position once each; these two items usually cannot be caught on a simulator. The integration time reserved for the modal before test entry has a typical range of half a day to a day, especially when a long list is behind it.

Cost ranges of several locking methods and the cost of position restoration

The following are common practices in 2026 projects. The differences are mainly how cleanly they lock, how much change is required, and whether position restoration needs extra handling. No single method covers every scenario.

• Locking the overflow of an inner scroll container: Small change, usually within an experience range of around half an hour to wire up; position is generally preserved, but it does not cleanly intercept iOS inertia and multi-layer scroll containers.
• fixed plus negative top compensation: Locks relatively cleanly and suits position-sensitive scenarios such as product detail pages and long lists; the cost is that scrollTop must be recorded and restored, with integration estimated at an experience range of half a day to a day.
• touchmove plus preventDefault: Cross-platform behavior is relatively consistent, suitable for confirmation dialogs that do not need scrolling inside the modal; the pitfall is that you must judge by event source, otherwise scrollable areas inside the modal are disabled too.
• Mature modal components or platform-native modals: Most already have locking and restoration built in and suit tight schedules; still confirm on a real device with the target OS version, not just by reading documentation.

For acceptance, fix two hard criteria: no obvious background displacement, and the scroll position after close matching that before open. Both can be reproduced on a real device and are easier to use as a delivery standard than “looks fine.”

Applicable scenarios and boundaries

The prerequisites for handling this are: mobile-first, background content clearly longer than one screen, and the modal stays open until the user actively closes it, such as filter panels, spec selection, and form modals. The criterion can be simplified to one: if the user might scroll the background while the modal is open, it is worth handling.

• Worth handling: H5 campaign page modals, mini-program spec selection, confirmation modals in App-embedded WebViews, and form modals with input fields.
• No locking needed: single-screen landing pages that do not scroll, desktop-first admin systems, and lightweight toasts that auto-dismiss in 1 to 2 seconds.
• Needs extra evaluation: when a page embeds many third-party SDKs or ad slots, scroll locking may affect their own scroll logic; run a regression round before release.
• Boundary note: if the project already uses a mature modal component and there is no online feedback about scroll-through or jump-to-top, there is generally no need to rewrite it just for consistency.

FAQ

Does locking a container with only overflow:hidden really lose position?

Mostly no. It does not change document flow, so position is usually preserved; position loss appears more in position:fixed solutions because the container is taken out of normal layout, and scrollTop must be manually written back on close.

When recording scrollTop and restoring it, what else should be noted?

Pay attention to restoration timing and the source of the value. A common practice is to record the container's current scrollTop when opening, write it back after the close animation finishes, and confirm the modal has been removed, otherwise it may be reset again.

If the same modal does not lose position on Android but does on iOS, should they be handled separately?

The common reason is that the two systems differ in inertial scrolling and visual viewport behavior. With a fixed solution, both platforms need explicit restoration; if you only fix Android, iOS will still jump back to the top.

If the modal has an input field and the position becomes disordered after the keyboard is dismissed, is that the same type of issue?

Related but different. The keyboard changes the visual viewport height. A common practice is to recalculate the height after dismissal or directly restore the scroll position from before opening; otherwise it leaves half a screen of blank space or an offset.

How much testing before release is enough?

There is no unified hard standard. A common practice is to cover mainstream iOS versions and one or two mid-to-low-end Android devices, test at least once with a long-list modal and once with an input modal, and then confirm the position is consistent after close.

In practice, complete scroll locking and position restoration as one operation: first confirm which layer the scroll occurs in, then choose a locking method, record on open and restore on close, and finally add real-device scrolling and close position to the regression checklist. If the project's modal comes from a mature component and there is no related online feedback, there is no need to rewrite it for consistency; for mobile-first H5 or mini-programs, it is advisable to run these two checks before test entry, because the later they are found, the larger the rework scope.