NEW292603
Safari on iOS adds bottom offset to viewport when keyboard is open 
https://bugs.webkit.org/show_bug.cgi?id=292603
Summary Safari on iOS adds bottom offset to viewport when keyboard is open
Svyatoslav Zaytsev
Reported 2025-05-06 04:53:54 PDT
Created attachment 475144 [details] Screenshot with bug On iOS Safari (and WKWebView), the root scrollable area always extends by a fixed blank strip at the bottom—equal to the Home-indicator “safe area” inset—regardless of whether a software keyboard is shown or a hardware keyboard is attached. Even when html/body are constrained to 100vh, 100dvh or -webkit-fill-available, this extra region remains scrollable and cannot be suppressed by any combination of overflow, overscroll-behavior or viewport‐unit hacks. ### Reproducion ```html <html> <head> <meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1.0,user-scalable=0" /> <style> html { height: 100%; overflow: hidden; overscroll-behavior: none; border: 2px solid #000; } body { margin: 0; height: 100%; overflow: hidden; display: grid; grid-template-rows: 40px 1fr 40px; } header, footer { height: 40px; background: red; } main { background: linear-gradient(to bottom, #000, #fff); overflow-y: auto; -webkit-overflow-scrolling: touch; overscroll-behavior: contain; } </style> </head> <body> <header></header> <main> </main> <footer> <input type="text" /> </footer> </body> </html> ``` ### Steps to reproduce 1. Create and serve html file with content above 2. Open this page on an iPhone (iOS 15/16/17) in Safari or an embedded WKWebView 3. Focus input (should open keyboard) 4. Try to scroll down over footer ### Actual behavior You can scroll below footer. A blank “gap” appears below the footer, equal to the Home-indicator safe-area inset. That gap is scrollable (“bounce” overscroll) even though no content occupies it. Neither 100vh, 100dvh/svh nor -webkit-fill-available resize to exclude that safe-area region. ### Expected behavior The safe-area inset at the bottom should be consumed by the viewport’s layout: the visible page area ends at the bottom of the footer. No extra blank scrollable region should appear below real content—i.e., the root scrollable extents should match the visual viewport minus the keyboard area. Dynamic viewport units (vh, dvh, svh) and -webkit-fill-available should all reflect only the usable screen area, excluding any safe-area insets.
Attachments
Screenshot with bug (273.23 KB, image/png)
2025-05-06 04:53 PDT, Svyatoslav Zaytsev 		no flags
Details
Expected behavior (348.75 KB, image/png)
2025-05-06 04:55 PDT, Svyatoslav Zaytsev 		no flags
Details
iOS 18.1 Simulator (280.22 KB, image/png)
2025-05-08 07:42 PDT, Svyatoslav Zaytsev 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Svyatoslav Zaytsev
Comment 1 2025-05-06 04:55:17 PDT
Created attachment 475145 [details] Expected behavior
Alexey Proskuryakov
Comment 2 2025-05-06 09:10:22 PDT
Thank you for the report! You say that this happens with iOS 15/16/17. Could you please clarify whether this reproduces with the latest version, 18.4.1 or 18.5 seed?
Svyatoslav Zaytsev
Comment 3 2025-05-08 07:42:04 PDT
The latest version available for me is iOS 18.1 (Simulator). This problem happens on this version too.
Svyatoslav Zaytsev
Comment 4 2025-05-08 07:42:32 PDT
Created attachment 475168 [details] iOS 18.1 Simulator
Radar WebKit Bug Importer
Comment 5 2025-05-13 04:54:13 PDT
<rdar://problem/151215752>
Kerim
Comment 6 2025-09-29 03:02:33 PDT
Hello! Any news on this bug? I'm facing this issue on my WKWebView page. When I focus any input on my webview page keyboard appears and adds some blank space below bottom fixed elements and this blank space is scrollable. Also keyboard pushes all page's content up on appearing. I don't know is it related to this bug, but I thought it is worth to mention that.
Note You need to log in before you can comment on or make changes to this bug.