[Android] Timing of NativeCommands delivery vs. calls of TurboModule methods vs. AppState changes

birdofpreyru commented 2 months ago

Description

Not sure, is it a bug, or a peculiarity of the new architecture, but here is my scenario. My app uses RN 0.74.2, with new arch, bridgeless. It has an internal web server (my @dr.pogodin/react-native-static-server — a TurboModule), and it has a WebView (my slightly enhanced fork of react-native-webview — a Fabric component), which loads assets from that web server. When the app goes into background I want to abort any in-flight loading by RN WebView, and then shutdown the server. To do so, I listen for AppState change, and when the state changes to background I call RN WebView's stopLoading() method, and my server's stop() command; both calls are passed to the native side, via Fabric's NativeCommand in WebView case, and via TurboModule method call in my server's case.

Now I am testing it on Android, with a bunch of debug logging, and native debugger at hands. I see the following:

I send my app to the background.
Both WebView's stopLoading() and server's stop() are called in JS layer.
The server's TurboModule stop() operation is successfully executed in the native layer, and it even manages to emit back a notification that server stopped (using RCTDeviceEventEmitter) so that in JS layer a message is printed to the console that server successfully stopped.
However; the WebViews stopLoading() command is not triggered at the native side — not until the app is brought back to the foreground again, immediately after which I capture by the debugger that it has been triggered.

My expectation here, especially considering that TurboModule has no problem to trigger native call, and deliver backward event to JS immediately after the app state changed to background, that the same should work for Fabric components; however, it is not the case. What do you think? Is it a bug? Or a limitation of the current new arch implementation for components? Or is it RN WebView's code uses a stale approach to operate native commands (though, it seems it follows what is currently documented here)?

Steps to reproduce

N/A

React Native Version

0.74.2

Affected Platforms

Runtime - Android

Areas

Other (please specify)

Output of `npx react-native info`

N/A

Stacktrace or Logs

N/A

Reproducer

https://github.com/birdofpreyru/issue-45017

Screenshots and Videos

No response

cipolleschi commented 2 months ago

Hi @birdofpreyru, thanks for the issue.

I feel this is a bug/undocumented behavior. My hypothesis is that when you put the app in background, the Component tree is unmounted so the command is not sent, but stored in some kind of queues. As soon as the app comes back to foreground, the component is remounted, the queue flushed and the command executed.

If that the case, it should be easy to create a simple reproducer using this template, where you can add react-native-webview as a dependency. This would help us investigate whether this is the case. I don't have a clean and quick solution for this problem, it might require us some architectural discussion, but it is definitely something we want to understand and we want to get to the bottom of this!

birdofpreyru commented 2 months ago

Sure @cipolleschi , here you are: https://github.com/birdofpreyru/issue-45017

After doing yarn, you probably want to open its android project in Android studio, locate react-native-webview/kotlin+java/com.reactnativecommunity.webview/RNCWebViewManagerImpl.kt, and set a breakpoint at the line number 314 (it reads "stopLoading" -> webView.stopLoading()).

Then run the app from Android studio in debug mode (and with dev server running):

It opens, loads RN website.
You hit the home screen button of emulator (or device)
The app goes into background, an (NOBRIDGE) LOG Entering background! is printed in the dev server console, the breakpoint in native code is not hit.
Now you press the app icon in emulator to bring it back to the foreground — now the breakpoint for stopLoading() is hit.

cipolleschi commented 2 months ago

Thanks for the reproducer, we will look into it as soon as we are done with the release of 0.75.0-rc1

facebook / react-native