iOS 26 Safari & WebView: VisualViewport.offsetTop not reset after keyboard dismissal, causing fixed elements misplacement

1. System/device combinations where the issue does not occur:

Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max

2. System/device combinations where the issue does occur:

System versions:

Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339)

Device models:

Physical device: iPhone 12

Reproducible in Safari, WKWebView, and UIWebView:

Yes

Actual behavior

In WebView (and identically in Safari):

  • Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.

  • After the keyboard appears, the visualViewport position changes.

  • Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:

    • When scrolling down, the position looks correct.
    • When scrolling up, the header/footer are visibly offset.

Steps to reproduce

  1. Focus an input field → the keyboard appears
  2. Dismiss the keyboard
  3. Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
  4. position: fixed header/footer elements are misplaced relative to the screen

Expected behavior

  1. After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
  2. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.

Minimal reproducible demo

A simple HTML file containing:

  • A header and footer with position: fixed
  • An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
        <title>H5 吸顶吸底页面 Demo</title>
        <style>
            * {
                margin: 0;
                padding: 0;
                box-sizing: border-box;
            }

            body {
                font-family: Arial, sans-serif;
                height: 2000px; /* 设置内容高度 */
                background-color: #f0f8ff; /* body 背景浅蓝色 */
                padding-top: 120px; /* 预留 header 高度 */
                padding-bottom: 60px; /* 预留 footer 高度 */
                overflow-x: hidden;
            }

            /* 吸顶 Header */
            header {
                position: fixed;
                top: 0;
                left: 0;
                width: 100%;
                height: 120px;
                background-color: #ff6b6b; /* 红色 */
                display: flex;
                align-items: center;
                justify-content: center;
                color: white;
                font-size: 24px;
                font-weight: bold;
                z-index: 1000;
            }

            /* 吸底 Footer */
            footer {
                position: fixed;
                bottom: 0;
                left: 0;
                width: 100%;
                height: 60px;
                background-color: #4ecdc4; /* 青绿色 */
                display: flex;
                align-items: center;
                justify-content: center;
                color: white;
                font-size: 18px;
                font-weight: bold;
                z-index: 1000;
            }

            /* 输入框样式 */
            .input-container {
                margin: 100px auto;
                width: 80%;
                max-width: 600px;
                text-align: center;
            }

            input[type='text'] {
                padding: 12px;
                font-size: 16px;
                border: 2px solid #ddd;
                border-radius: 8px;
                width: 100%;
                box-sizing: border-box;
            }

            input[type='text']:focus {
                outline: none;
                border-color: #4ecdc4;
            }
        </style>
    </head>
    <body>
        <!-- 吸顶 Header -->
        <header>吸顶 Header (120px)</header>

        <!-- 主体内容 -->
        <div class="input-container">
            <input type="text" placeholder="请输入内容..." />
        </div>

        <!-- 吸底 Footer -->
        <footer>吸底 Footer (60px)</footer>
    </body>
</html>
Answered by DTS Engineer in 857887022

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

I checked Apple’s official Support Community page, and the same issue with incorrect positioning of fixed elements also occurs after triggering the keyboard. Here are related StackOverflow discussions on the same problem:

iOS 26 Safari - Web layouts are breaking due to fixed/sticky position elements getting shifted vertically

iOS 26 Safari visualViewport change after dismissing keyboard

Upon further investigation, my initial assumption that “VisualViewport.offsetTop is not being restored” appears to be inaccurate. In Safari, when continuously swiping upward, offsetTop eventually becomes 0 or very close to 0. However, visualViewport.height consistently remains smaller than window.innerHeight, and as a result, the position of fixed elements remains incorrect and does not align with the expected behavior.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

Sure! Here's a polished response in English:


I have the same issue. When using the following CSS:

position: fixed;
bottom: 0;

The problem arises when the keyboard is triggered and later hidden. After this, the position of the bottom element is broken, and bottom: 0 no longer works as expected.

@DTS Engineer Our website has encountered the same fixed location offset issue on iOS26. We kindly request you in resolving this matter. It would be best before the official release of iOS26.

We're experiencing the same issue, it seems to be a major regression

@hibye seems spot on about the issue, also as reported in this stackoverflow post: https://stackoverflow.com/questions/79758083/ios-26-safari-visualviewport-change-after-dismissing-keyboard

before opening the keyboard, visualViewport.height and window.innerHeight match... but after opening the keyboard there's always a 24px difference (and this persists after the keyboard is closed)

@DTS Engineer I just upgraded Xcode to version 26 and downloaded the official release of iOS 26. The issue with fixed elements being incorrectly positioned after the keyboard has been pulled up within a WebView still exists. I hope Apple can intervene and address this as soon as possible. The changes in iOS 26 have affected web pages across the entire internet.

Hi,

This is the worst Safari update in years.

The use of elements with 100% height in fixed/absolute position is completely broken.

It's really unacceptable that this is live.

Im facing the same since 26 ios beta versions. The same behavior like hibye was mentioned here. It wasnt happened on ios18. i have opened a feedback FB19889436 few weeks ago, however the current explenation in this topic describe better the issue.

Apple's response to this issue has been incredibly slow. The DTS engineers seem like robots. Numerous people have filed feedback, and this post has been up for several days, yet no real Apple engineer has stepped in to address it. @Maxoou

What is going on at apple? How are you not ashamed of this?

I often integrate pop-ups/drawers that cover 100% of the width and 100% of the height of the screen.

Since iOS 26, the behavior on Safari has changed and it is no longer a true 100% height because of this floating bar.

The overlays of these pop-ups/drawers no longer cover 100% of the height, which looks very ugly.

same for me, Website with 100k+ Users, already got several complaints.

Same issue here in a WebView. Opening keyboard makes fixed elements move on future scrolls.

Behavior bugs don't only occur when opening/closing the keyboard.

It's the overall behavior of elements in sticky/absolute/fixed positions that are broken because of this new weird viewport.

For example, if you go to Apple's website (https://www.apple.com/) and scroll down, the header will be sticky, but if you look closely, part of the header will extend a few pixels above the viewport.

This is the bug report on Webkit's tracker: https://bugs.webkit.org/show_bug.cgi?id=297779

Might be worth chiming in there to get their attention.

This even happens on the Apple website, for example when viewing feature details on the iPad Air website

What is going on with that? anyone has any update?

It's absolutely wild to me that Apple has not responded to this yet?

Millions of business critical websites are broken, including their own website Apple.com.

Ours is completely mangled too - i've honestly never seen worse pushed to browser production.

@Enzagi thanks for filing FB19889436. I checked on the status of your bug repot and it is in the process of being routed to the engineering team. I added some notes in there asking for it to be routed to a specific group.

In the iOS 26 public beta I see that the fixed position is working again. One issue that remains broken is if you turn on "Reduce Motion" (Settings->Accessibility->Motion->"Reduced Motion"), then turn on "Prefer Cross-Fade Transitions" the fixed position is quite messed up. I see the elements that should be positioned on the bottom of the screen roughly halfway up the screen on scroll up.

I think it's worth noting that there are a number of other posts. Please consider filing bug reports as well and posting the bug numbers here. Duplicates matter and help engineering quantify how many developers are affected by an issue.

Bug Reporting: How and Why? has tips on creating your bug report.

In iOS 26.1 beta the problem seems to be resolved for me. Can anyone confirm if it has also been fixed in version 26.0.1? I’d prefer not to downgrade just to check.

Thanks!

I just update to 26.0.1 and the problem was not solved.

iOS 26 Safari & WebView: VisualViewport.offsetTop not reset after keyboard dismissal, causing fixed elements misplacement
 
 
Q