Startup race condition on second launch where window.Capacitor is undefined, causing unexpected triggerEvent errors in live builds despite no related code changes

In our production Capacitor android app, we’ve started seeing intermittent runtime errors such as:

Uncaught TypeError: Cannot read properties of undefined (reading 'triggerEvent')

This appears during app startup on the second launch and after, and the stack trace points to window.Capacitor.triggerEvent("keyboardDidHide", "window"). What makes this more concerning is that on Android the failure occurs before our JavaScript code even begins executing, which strongly suggests the issue is happening inside the Capacitor runtime or a plugin, not inside our application logic.

From testing and logging, it appears that window.Capacitor is sometimes not initialized early enough, which causes internal plugin events possibly from the Capacitor Keyboard plugin to run before the bridge exists. This would explain why the same error suddenly appears across multiple older versions of our app, even though we made no related code changes.

This points to a possible regression or timing issue within the Capacitor Keyboard plugin or Capacitor’s initialization sequence on Android. Any insight into why the bridge is not consistently available before plugin events fire would be appreciated.

The issue disappears temporarily when adding simple logging statements, which reinforces the idea that this is a race condition.

This behaviour seems new and inconsistent with how Capacitor has behaved historically. We are trying to understand:

  • Why window.Capacitor is not consistently available before the app bundle executes

  • Why internal plugin code is calling triggerEvent() before initialization

  • Whether this is a known regression or timing issue in recent Capacitor versions or WebView updates

Any insight into why these previously-stable builds suddenly began exhibiting this error would also be appreciated.

1 Like

I also have seen this, it’s very hard to debug because we are not calling triggerEvent anywhere in our codebase, so presumably it’s happening somewhere in Capacitor? Also in production!

This has now been resolved. We were using a beta version of the android web view as our test devices were enrolled onto the android test programme. There must’ve been a change gone in to the beta version which caused this weird behaviour