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時間
- マージ済み PR(30日)
- 3
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 が今日担当しました。 オープン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
-
API `/api/dataverses/{identifier}/dataset/linkingDataverses?alreadyLinking=true` returns at most 1 collection対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンType: Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
javaoperatorsdk.client.oauth-token has no effect on the Kubernetes client対応中かも @RaphaelFakhri が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
MCP add-on: JSON responses with non-ASCII characters are truncated (wrong Content-Length)対応中かも @dhanushbs10 が今日担当しました。 オープンadd-on bug in:mcp
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
Map.Coordinate does not implement proper equals対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンvaadin-map
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
vaadin/flow-components#10586 ·
メンテナーはふだん 1 日以内に返信
-
WeReadInstaller writes the launcher database on the main thread at handover (Activity pause timeout)オープンbug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100