Inconsistent Android back button behavior while navigated to a modal view

[trjExpensify]

If you haven’t already, check out our contributing guidelines for onboarding!

---

Expected Result:

The Android hardware back button should work when pressed.

Actual Result:

When you open the settings page the first back button press is ignored (as if an extra invisible page was added to the page stack), but the second and third back button press work as expected.

Action Performed:

1. Open the settings modal
2. Press the back button

Platform:

Android

Notes/Photos/Videos:

• This issue is caused by a bug in react-navigation and must be fixed in that repo first.
• See: Hardware back button on android doesn't work on the first press react-navigation/react-navigation#9364
• Workarounds will not be accepted.

Expensify/Expensify Issue URL:
https://github.com/Expensify/Expensify/issues/157248
Upwork link: https://www.upwork.com/jobs/~016d2a711284ef2fc7

[sohaibkhaa]

I will fix the issue by manipulating the app behaviour and debugging to check whether is there any other page opened while opening the settings page. After finding the bug try to resolve it by updating the part of code that is used to open up settings page. And debug the back press behaviour of settings page.

[ahmedahtazaz]

While reviewing through the job I have noticed that there is no custom hardware back button handling in your app. Well in my experience it is a must for Android. This is a normal issue while building cross-platform apps with React Native because the developer is mostly focused on one platform and expect it to work on both of them.

[parasharrajat]

@ahmedahtazaz Doesn't react-navigation gives that by default?

[ahmedahtazaz]

@parasharrajat Yes react-navigation gives it by default but there are some scenarios in which it does not work properly. That's the very reason there are lots of back button issues reported over the time specially for Android. You can check stack-overflow for relevant issues.

[ahmedahtazaz]

So in my point of view custom back button handling is needed in these scenarios.

[kaushiktd]

Hi,

This is Kaushik here and here is explanation for this,

1. Maybe a configuration issue in the stack, will be resolved by stack management or manage back handler on a specific page on the single back

[marcaaron]

@ahmedahtazaz I'm not too sure what the exact proposal is here yet. Can you briefly outline the changes you intend to make and point to some specific area in the code?

[ahmedahtazaz]

@marcaaron I have attached a screenshot that points to the point in code where I will add a custom back button handler. This handler will receive all the back button press events. I will check the routes here and if the current route is settings/preferences i will executes this function: Navigation.navigate(ROUTES.SETTINGS)Navigation.navigate(ROUTES.SETTINGS)

In this way the back button handling will be delegated to the PreferencesPage instead of HeaderWithCloseButton.

I hope my solution is clear now.

[marcaaron]

It's still unclear to me sorry. The docs state:

By default, when user presses the Android hardware back button, react-navigation will pop a screen or exit the app if there are no screens to pop. This is a sensible default behavior, but there are situations when you might want to implement custom handling.

If the "sensible default behavior" is that a back button press should return us to the last place we were (which in this case should dismiss the settings screen and display the side bar again).

But the issue states:

When you open the settings page the first back button press is ignored

So, I don't see how the custom back button handler helps us here. Why is the first back button press ignored?

[marcaaron]

Looked into this a bit and surely this is the bug here...

react-navigation/react-navigation#9364

Ideally, this would get fixed in the react-navigation library. But I think we'll need to implement this same solution in all screens. So if we implement the work around it should happen in the ScreenWrapper component and we should link to that issue so it can be fixed by upgrading eventually.

[ahmedahtazaz]

@marcaaron here is the catch. When I will add a custom back button handler the first hardware back press will give me the actual route or the actual current route in the navigation stack. Then we will have a very good understanding if there is a screen on top of the preferences screen or not. Custom back handling will be used as a debugging strategy here as well.

[ahmedahtazaz]

@marcaaron as a matter of fact I did not know about this bug react-navigation/react-navigation#9364.

Thanks for this information. Yes implementation of custom back handler in ScreenWrapper will be generic and will fix this issue in all screens where this wrapper is being used.

[ahmedahtazaz]

Please let me know if I should start working on this or if you are delegating it to someone else.