[Bug]: [ios] Some Native -> JS messages appear to drop after extended time with app in background

[gabeschine]

Capacitor Version

💊 Capacitor Doctor 💊

Latest Dependencies:

@capacitor/cli: 6.2.0
@capacitor/core: 6.2.0
@capacitor/android: 6.2.0
@capacitor/ios: 6.2.0

Installed Dependencies:

@capacitor/android: not installed
@capacitor/core: 6.2.0
@capacitor/ios: 6.2.0
@capacitor/cli: 6.2.0

[success] iOS looking great! 👌

Other API Details

yarn --version: 1.22.11
node --version: v20.10.0

Platforms Affected

• iOS
• Android
• Web

Current Behavior

If a Capacitor app is backgrounded for a long time, and during this time a notification is delivered to the device and clicked or a deeplink open request is received, when the app is foregrounded the relevant message (either the notification payload from a plugin like @capacitor/push-notifications or the appUrlOpen event from @capacitor/app) is sometimes dropped.

In the field when this occurs, we observe the app's web view reload immediately upon foregrounding.

In testing, it is possible to reproduce the behavior, and it appears to be tied to the timing of iOS notifying the native app through webViewWebContentProcessDidTerminate [1]: if the notification happens immediately, messages are delivered successfully; if the notification is delayed until the app is foregrounded, the messages are not delivered.

[1] https://developer.apple.com/documentation/webkit/wknavigationdelegate/webviewwebcontentprocessdidterminate(_:)

Expected Behavior

The messages are delivered in all scenarios.

Project Reproduction

https://github.com/watch-duty/capacitor-message-bug-repro

Additional Information

The reproduction is not a perfect mirror of what happens in production.

In production: it appears that iOS is killing the WebContent process on its own. Based on reading this can happen to reduce memory pressure or other resource pressure, or based on other conditions unknown to me.

In the reproduction: killing the WebContent process is performed explicitly, since it is impossible to deterministically trigger the same resource pressure conditions encountered in production.

The reproduction is assuming that while the trigger is different, the subsequent symptoms and bug mechanism are shared. Based on many, many user reports of the bug, and associated data gather that we have performed, this appears to be a sound assumption.

[davidemerritt]

+1 here - this reflects what I've seen in our application as well, affecting push notification handling.

[markemer]

This is somewhat expected behavior from iOS. iOS will kill you for any reason at any time. But, we shouldn't be dropping Native to JS calls, but I expect this is gonna be an interesting one to solve.

@gabeschine and @davidemerritt have you investigated using ionic-team/capacitor-background-runner? while I investigate?

Also, @davidemerritt, if you could add a reproduction to this ticket as well, I'd appreciate it. The more data the better.

[gabeschine]

This is somewhat expected behavior from iOS. iOS will kill you for any reason at any time. But, we shouldn't be dropping Native to JS calls, but I expect this is gonna be an interesting one to solve.

Understood - expected given the systems in question. I agree with your qualifier, though :). Let me know if you'd like to chat through possible approaches.

@gabeschine and @davidemerritt have you investigated using ionic-team/capacitor-background-runner? while I investigate?

Took a quick look. After processing a notification, we will need to communicate with the JS process in the WebView to mutate the router to set the window location to the correct path. Given that requirement, I'm not immediately seeing how a background task would help: it looks like the background task would have a chance to process the notification payload, but then that information would still need to be sent to the foreground WebView once it's spun back up.

Also, @davidemerritt, if you could add a reproduction to this ticket as well, I'd appreciate it. The more data the better.

Dave works with me 😇. Apologies if that was misleading. The reproduction I attached here went through many iterations: I believe it's pretty robust.

[ionitron-bot]

This issue has been labeled as type: bug. This label is added to issues that that have been reproduced and are being tracked in our internal issue tracker.

[gabeschine]

Hello @markemer -

I'd like to pick this bug back up. I have some cycles to work on a fix, unless you already have made some progress. Would it be useful to chat about a specific approach and how to proceed in terms of the actual work?

My basic idea is to add explicit message acknowledgement to the iOS bridge native -> JS message pathway. The iOS CapacitorBridge would hold onto messages until it receives acknowledgement that they have been received by the JS side. If the JS context is reinitialized and unacknowledged messages are in the native -> JS queue, they would be re-issued.

Let me know how you'd like to proceed.

[DMills03]

We're experiencing the same issue here with our app and would appreciate if there could be any movement on this 🙌

[gabeschine]

We're experiencing the same issue here with our app and would appreciate if there could be any movement on this 🙌

Having not heard back, I got started on a PR. I'll update here once it's posted.

[markemer]

Hello @markemer -

I'd like to pick this bug back up. I have some cycles to work on a fix, unless you already have made some progress. Would it be useful to chat about a specific approach and how to proceed in terms of the actual work?

My basic idea is to add explicit message acknowledgement to the iOS bridge native -> JS message pathway. The iOS CapacitorBridge would hold onto messages until it receives acknowledgement that they have been received by the JS side. If the JS context is reinitialized and unacknowledged messages are in the native -> JS queue, they would be re-issued.

Let me know how you'd like to proceed.

Yeah, absolutely, I haven't had a tone of time to dig through this, thanks for the draft PR, I'll take a look at what you've got so far.