frontend/android: check if webview can go back or close the app

[thisconnect]

This should replace native Android back behavior with either going back in the webview history or closing the app.

In theory the react-router pushes history entries to the webview navigation history, as soon as the user clicks a Link or navigate is called. The navigate function can also be called with replace option so that it does not add to the history.

This is using the native goBack method but it seems that the app only goes back to account summary. In theory this should behave the same as native browser back. It is not clear why it jumps to the beginning.

So this could probably be improved, but seems already useful with just going back to the account summary.

On the account summary it cannot go back any further so it will trigger the old do-you-want-to-quit alert.

Replaced deprecated onBackPressed override.

[benma]

Would be good to describe the behavior more clearly. When/where does a navigation add to the navigation history? A way to unit test this stuff would be very nice, to document the navigation behavior clearly.

I also wonder how robust this is - can a change like https://github.com/digitalbitbox/bitbox-wallet-app/pull/2524 change this behavior? Again some sort of automated tests would be very very good to have for this.

[thisconnect]

A way to unit test this stuff would be very nice, to document the navigation behavior clearly.

To be explicit, you want to test vw.canGoBack() and vw.goBack() and or the whole thing around it?

I guess that would be very nice. I have no idea what that takes, would it test with a real webview with our production bundled.js and simulating user clicking in react UI and then simulating webview.goBack() and testing if the URI is correct?

Sounds to me more like integration / e2e test, rather than unit test? As far as I see we don't have any java test or maybe I am blind.

Also I am afraid that I have no idea how to setup something like this.

I also wonder how robust this is - can a change like https://github.com/digitalbitbox/bitbox-wallet-app/pull/2524 change this behavior? Again some sort of automated tests would be very very good to have for this.

I don't see any reason why it shouldn't work, but I will test this branch on top of #2524 . I believe worst case vw.canGoBack() does not return true and then it calls the old code (alert + quitting the app).

When/where does a navigation add to the navigation history?

This is a good question. There is history.pushState https://developer.mozilla.org/en-US/docs/Web/API/History/pushState to add entries to the browser history. And it looks like our router somehow adds history entries, but I am not sure why it doesn't correctly go back when calling vw.goBack();. Afaik react-router does window.history.pushState, but I will try to check.

[thisconnect]

rebased

[thisconnect]

can a change like https://github.com/digitalbitbox/bitbox-wallet-app/pull/2524 change this behavior?

here is a POC with this commit on top of #2524 it seems to behave the same. https://github.com/digitalbitbox/bitbox-wallet-app/pull/2705

[benma]

A way to unit test this stuff would be very nice, to document the navigation behavior clearly.

To be explicit, you want to test vw.canGoBack() and vw.goBack() and or the whole thing around it?

I guess that would be very nice. I have no idea what that takes, would it test with a real webview with our production bundled.js and simulating user clicking in react UI and then simulating webview.goBack() and testing if the URI is correct?

Sounds to me more like integration / e2e test, rather than unit test? As far as I see we don't have any java test or maybe I am blind.

Also I am afraid that I have no idea how to setup something like this.

I also wonder how robust this is - can a change like #2524 change this behavior? Again some sort of automated tests would be very very good to have for this.

I don't see any reason why it shouldn't work, but I will test this branch on top of #2524 . I believe worst case vw.canGoBack() does not return true and then it calls the old code (alert + quitting the app).

When/where does a navigation add to the navigation history?

This is a good question. There is history.pushState https://developer.mozilla.org/en-US/docs/Web/API/History/pushState to add entries to the browser history. And it looks like our router somehow adds history entries, but I am not sure why it doesn't correctly go back when calling vw.goBack();. Afaik react-router does window.history.pushState, but I will try to check.

The tests don't have to be inside Android/Java, you can assume it works like a Chromium browser.

It would just be very good if we had a good list of tests (manual tests in the worst case, automated would be best) that show that history-back goes to the expected place. Worse than a back button that closes the app is one that does not work as expected :smile:

[thisconnect]

It would just be very good if we had a good list of tests (manual tests in the worst case, automated would be best) that show that history-back goes to the expected place. Worse than a back button that closes the app is one that does not work as expected 😄

unfortunately it already does not work as expected. I expect that it does history back, but it always just goes back to account summary. I am not sure why, and am not sure how to remote debug right-now.

In webdev history back works as expected.. It would be very nice if both behave the same, need to investigate what exactly is happending in the webview when we call goBack() (or the js version vw.evaluateJavascript("history.back();", null);)

[thisconnect]

testing if initializing with correct historyUrl changes the goBack behavior.

[thisconnect]

closing in favor of https://github.com/BitBoxSwiss/bitbox-wallet-app/pull/2819