Skip to content

[Bug]: SystemBars omits the iOS statusTap bridge#8583

Description

@eabbott-dev

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

  • iOS
  • Android
  • Web

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:

  1. With only core SystemBars installed, tapping the iOS status bar produces no statusTap event and the page does not scroll.
  2. 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)
    }
  }
}

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs reproductionneeds reproducible example to illustrate the issue

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions