Capacitor Version
馃拪 Capacitor Doctor 馃拪
Latest Dependencies:
@capacitor/cli: 8.5.0
@capacitor/core: 8.5.0
@capacitor/android: 8.5.0
@capacitor/ios: 8.5.0
Installed Dependencies:
@capacitor/cli: 8.5.0
@capacitor/core: 8.5.0
@capacitor/android: 8.5.0
@capacitor/ios: 8.5.0
[success] Android looking great! 馃憣
[success] iOS looking great! 馃憣
Other API Details
npm --version: 10.9.2
node --version: v22.17.0
pod --version: 1.16.2
Platforms Affected
Current Behavior
In a Capacitor 8 iOS application using the core SystemBars API, tapping the iOS status bar does not dispatch the established window.statusTap JavaScript event. Consequently, Ionic does not scroll the active ion-content to the top.
This regression appeared after replacing @capacitor/status-bar with the new core SystemBars API during the Capacitor 8 migration.
Environment:
- @capacitor/core: 8.5.0
- @capacitor/ios: 8.5.0
- @ionic/vue: 8.6.7
- UIViewControllerBasedStatusBarAppearance: true
- Status bar visible
- Application uses an ion-app containing a scrollable ion-content
A listener added directly to the window is never invoked:
window.addEventListener('statusTap', () => {
console.log('statusTap received')
})
The native status-bar tap is still detected by Capacitor iOS and published through Notification.Name.capacitorStatusBarTapped. However, the core SystemBars plugin does not observe that notification or forward it to the web view.
The separate @capacitor/status-bar plugin does perform that forwarding:
bridge.triggerJSEvent(eventName: "statusTap", target: "window")
Therefore:
- With only core SystemBars installed, tapping the iOS status bar produces no statusTap event and the page does not scroll.
- Installing and registering @capacitor/status-bar restores the event and Ionic scroll-to-top behavior, even when SystemBars remains responsible for styling and edge-to-edge layout.
This means applications must retain the complete legacy Status Bar plugin solely to preserve the iOS tap event, despite migrating status-bar styling and layout to the Capacitor 8 core API.
Expected Behavior
When using Capacitor 8鈥檚 core SystemBars API on iOS, tapping the visible status bar should dispatch one statusTap event on window, preserving the established Capacitor behavior.
This should allow Ionic鈥檚 existing hybrid-app handler to scroll the active ion-content to the top without requiring the separate legacy @capacitor/status-bar dependency.
At minimum, if omitting statusTap support from SystemBars is intentional, the System Bars documentation and feature comparison should explicitly state that applications must retain @capacitor/status-bar to preserve iOS status-bar tap and scroll-to-top behavior.
Project Reproduction
Reproduction to follow
Additional Information
There is an undocumented feature parity regression between SystemBars and the legacy @capacitor/status-bar plugin.
SystemsBars should either raise the statusTap event to allow iOS scroll-to-top behaviour, or the regression should be documented
As a workaround, the following bare-bones plugin can provide the required behaviour without including the full status-bar plugin
import Capacitor
import Foundation
@objc(StatusBarTapPlugin)
final class StatusBarTapPlugin: CAPPlugin, CAPBridgedPlugin {
let identifier = "StatusBarTapPlugin"
let jsName = "StatusBarTap"
let pluginMethods: [CAPPluginMethod] = []
private var statusBarTapObserver: NSObjectProtocol?
override func load() {
statusBarTapObserver = NotificationCenter.default.addObserver(
forName: .capacitorStatusBarTapped,
object: nil,
queue: .main
) { [weak self] _ in
self?.bridge?.triggerJSEvent(eventName: "statusTap", target: "window")
}
}
deinit {
if let statusBarTapObserver {
NotificationCenter.default.removeObserver(statusBarTapObserver)
}
}
}
Capacitor Version
馃拪 Capacitor Doctor 馃拪
Latest Dependencies:
@capacitor/cli: 8.5.0
@capacitor/core: 8.5.0
@capacitor/android: 8.5.0
@capacitor/ios: 8.5.0
Installed Dependencies:
@capacitor/cli: 8.5.0
@capacitor/core: 8.5.0
@capacitor/android: 8.5.0
@capacitor/ios: 8.5.0
[success] Android looking great! 馃憣
[success] iOS looking great! 馃憣
Other API Details
Platforms Affected
Current Behavior
In a Capacitor 8 iOS application using the core SystemBars API, tapping the iOS status bar does not dispatch the established window.statusTap JavaScript event. Consequently, Ionic does not scroll the active ion-content to the top.
This regression appeared after replacing @capacitor/status-bar with the new core SystemBars API during the Capacitor 8 migration.
Environment:
A listener added directly to the window is never invoked:
The native status-bar tap is still detected by Capacitor iOS and published through Notification.Name.capacitorStatusBarTapped. However, the core SystemBars plugin does not observe that notification or forward it to the web view.
The separate @capacitor/status-bar plugin does perform that forwarding:
bridge.triggerJSEvent(eventName: "statusTap", target: "window")Therefore:
This means applications must retain the complete legacy Status Bar plugin solely to preserve the iOS tap event, despite migrating status-bar styling and layout to the Capacitor 8 core API.
Expected Behavior
When using Capacitor 8鈥檚 core SystemBars API on iOS, tapping the visible status bar should dispatch one statusTap event on window, preserving the established Capacitor behavior.
This should allow Ionic鈥檚 existing hybrid-app handler to scroll the active ion-content to the top without requiring the separate legacy @capacitor/status-bar dependency.
At minimum, if omitting statusTap support from SystemBars is intentional, the System Bars documentation and feature comparison should explicitly state that applications must retain @capacitor/status-bar to preserve iOS status-bar tap and scroll-to-top behavior.
Project Reproduction
Reproduction to follow
Additional Information
There is an undocumented feature parity regression between SystemBars and the legacy @capacitor/status-bar plugin.
SystemsBars should either raise the statusTap event to allow iOS scroll-to-top behaviour, or the regression should be documented
As a workaround, the following bare-bones plugin can provide the required behaviour without including the full status-bar plugin