bug(status-bar): iOS WebView moves under the status bar after a full-screen modal is dismissed
维护者通常 1 天内回复
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- swift
- 领域
- mobile-dev
调研方向
Read the status-bar plugin’s iOS implementation, especially resizeWebView(), handleViewDidAppear, and capacitorViewWillTransition, then compare the reported behavior with the linked pull request #2626. The issue describes the reproduction steps and expected layout; completion means the WebView returns below the status bar after a full-screen modal is dismissed. A pull request is already open, so this work is underway.
由索引模型根据 Issue 内容生成。
描述
Bug Report
Plugin(s)
@capacitor/status-bar8.0.4@capacitor/browser8.0.5 (used to present the full-screen modal)
Capacitor Version
Installed Dependencies:
@capacitor/android: not installed
@capacitor/cli: 8.6.0
@capacitor/core: 8.6.0
@capacitor/ios: 8.6.0
[success] iOS looking great! 👌
Platform(s)
iOS
Current Behavior
With overlaysWebView: false, the WebView starts below the status bar after launch. After a full-screen modal is dismissed, the WebView fills the whole window again:
- The page content sits under the status bar.
- The status bar background view (
backgroundColor) is no longer visible. StatusBar.getInfo()still returnsoverlays: false.
The layout stays wrong until the next rotation. Rotating to landscape and back restores it.
The full-screen modal in the reproduction is Browser.open() with the default presentation style. With presentationStyle: 'popover' the layout stays correct.
Expected Behavior
After a full-screen modal is dismissed, the WebView is below the status bar again, and the status bar background view is visible, as before the modal was presented.
Code Reproduction
https://github.com/kidzki/capacitor-status-bar-repro
npm install && npm run build && npx cap sync ios- Run the app on an iPhone simulator. The yellow box shows
RESULT: OK. - Tap Open in-app browser (full screen), then close the browser.
- The yellow box shows
RESULT: BUG:window.innerHeightequalsscreen.height, and the sticky header sits under the status bar.
Configuration:
"StatusBar": {
"overlaysWebView": false,
"backgroundColor": "#ffffff",
"style": "LIGHT"
}
Other Technical Details
- Observed on the iPhone 18 Pro simulator, iOS 27.2, Xcode 27.2.
- Also observed in our app on a physical iPhone 17 Pro with iOS 26.6.4, 27.0.1 and 27.2. Our app opens
Browser.open()full screen for the login. - The page does not use
viewport-fit=cover. - The app shell is the unchanged
iostemplate fromnpx cap add ios(Capacitor 8.6.0).
Additional Context
CAPBridgeViewController.loadView() sets view = webView, so the WebView is the root view. When a full-screen modal is dismissed, UIKit sets the root view back to the full window bounds.
The plugin positions the WebView in resizeWebView(). It calls that function after setOverlaysWebView and after a rotation (capacitorViewWillTransition). On capacitorViewDidAppear, which also fires after the modal is dismissed, handleViewDidAppear calls setOverlaysWebView(config.overlaysWebView). That function returns early because the value did not change (if overlay == isOverlayingWebview { return }), so the plugin does not lay out the WebView again.
Possible fixes:
- Lay out again in
handleViewDidAppear. We tried this: it restores the layout, but the jump is visible becauseviewDidAppearfires after the dismiss animation. - Observe the WebView layer (
position,bounds) whileoverlaysWebViewisfalse, and move the WebView back below the status bar when its origin changes. We tried this: the layout is restored without a visible jump. A pull request with this change follows. - Capacitor core sends a notification from
viewWillLayoutSubviewsorviewWillAppear, and the plugin lays out there. Not tried. @capacitor/browserpresents with.overFullScreeninstead of.fullScreen, so UIKit keeps the presenting view in place. Not tried. This fixes only the browser, not other full-screen modals.
- 主要语言
- Java
- 星标
- 688
- 派生
- 691
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 3
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
ionic-team/capacitor-plugins 的其他 Issue
-
triage
难度 2/5 1-3 小时 新手友好度 80/100
ionic-team/capacitor-plugins#2627 ·
维护者通常 1 天内回复
-
triage
难度 2/5 1-3 小时 新手友好度 72/100
ionic-team/capacitor-plugins#2616 ·
维护者通常 1 天内回复
-
[@capacitor/app] iOS: 'Expression implicitly coerced from String? to Any' warning in getAppLanguage未关闭triage
难度 1/5 1 小时以内 新手友好度 88/100
ionic-team/capacitor-plugins#2604 ·
维护者通常 1 天内回复
-
bug(action-sheet, camera): on iPhone with Liquid Glass, action sheets show as a popover without the Cancel action可能已有人在做 @arblitroshani 于 4 天前认领。 未关闭platform: ios
难度 3/5 1-2 天 新手友好度 20/100
ionic-team/capacitor-plugins#2630 ·
维护者通常 1 天内回复
-
platform: ios
难度 4/5 3-5 天 新手友好度 35/100
ionic-team/capacitor-plugins#2624 ·
维护者通常 1 天内回复
查看 ionic-team/capacitor-plugins 的全部 Issue
相似的 Issue
-
Bug
难度 2/5 1-3 小时 新手友好度 60/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 68/100
Vakore/ZappierGames#285 ·
-
[S26b-4] Runbook and usage still describe deb suite as a pass-through runner whose skips do not fail未关闭priority: low Review effort [1-5]: 4 status: needs-triage type: bug
难度 2/5 1-3 小时 新手友好度 76/100
carlos-emr/carlos#6074 ·
维护者通常 1 天内回复
-
On Windows, a relative command with `/` is looked up in the PATH instead of the working directory未关闭
难度 2/5 1-3 小时 新手友好度 77/100
redhat-developer/lsp4ij#1896 ·
维护者通常 1 天内回复