Skip to content

"Insets" handling problematic when gesture navigation is on and "navigation indicator" is hidden

Summary

I found a bug in privacy browser that actually yielded to a deep dive into an OS feature related to how Insets are handled.

After a few exchanges (see the details for link to the issue opened in the app, which contains also videos from the developer and from my phone to show the different behavior) the developer found some pointers that makes him believe the issue is in the OS.

Another calyxos user confirmed he is affected by the issue: https://matrix.to/#/!aZmLRhgGyXgdVmhzoH:matrix.org/$kkF5AJ9pNXsLpGWPnf2i11qkc0OKCjqPlZXafV8fN04?via=matrix.org&via=calyx.dev&via=nitro.chat

The issue is actually only present if the "navigation indicator" is set to hidden.

I don't know if hiding the navigation indicator is a calyxos feature or not, I asked the developer to try hiding it (in case it is possible on his phone) and test.

Details

Original issue: https://redmine.stoutner.com/issues/1229

Developer's observations:

Thank you for the detailed logcat.

I think the core of this problem has something to do with how the OS is calculating insets. Notice the InsetsController line right here before the crash.

2024-10-11 15:44:39.869 9096-9096 InsetsController com.stoutner.privacybrowser.alt D hide(ime(), fromIme=true) 2024-10-11 15:44:39.895 9096-9096 AndroidRuntime com.stoutner.privacybrowser.alt D Shutting down VM 2024-10-11 15:44:39.899 9096-9096 AndroidRuntime com.stoutner.privacybrowser.alt E FATAL EXCEPTION: main

Insets are parts of the OS that force the app to get smaller, like the keyboard coming up from the bottom or a cutout for a camera. The OS calculates insets and resizes the app accordingly.

That would explain why this bug only manifests with the bottom app bar. The top app bar doesn't have to adjust for an inset when the keyboard is open. It would also explain why this only manifests when the homepage is set to a blank string. If the homepage is populated, they keyboard is not automatically displayed when the app starts, but if the homepage is null then the keyboard automatically displays because it the most likely user action is to type a URL.

Opening either of the drawers automatically closes the keyboard. Opening the options menu has to calculate the inset for the displayed keyboard so the menu is above it. In either case, if something in the OS hasn't fully initialized the inset caused by the keyboard being displayed, this could trigger a crash.

After reading the last developer's comment, I could confirm the following:

  • if I enable three button navigation there is no issue
  • if I enable gesture navigation and leave the navigation indicator shown there is no issue (this is how the developer's phone is configured according to the video he shared)
  • if I enable gesture navigation and hide the navigation indicator the issue is present.

Additionally I tried introducing a delay in the application code before the IME is closed, and the issue is NOT present also in this case. Hence is somehow related to "something being reduced while something else is getting expanded" (very technical, I know ;-) )