`refresh_historical_location` does not use current WebView location after form submission on modal bottom sheet

[noah44846]

Hi !

This is a follow-up on #122. There is this situation we found where the issue of the refresh on the initial URL instead of the new one still persists. It happens after form submission that redirects to /refresh_historical_location inside a modal bottom sheet. In this situation, the modal gets dismissed and the page behind it gets refreshed but with the "old" URL.

I made a fork of the demo app to make a reproducible example of the issue.

Thanks!

[fiedl]

We observe the same thing. Did you find a solution or workaround? Thank you very much!

[fiedl]

We did also observe this with the demo application itself.

hotwire-native-android

The following is the hotwire-native-android demo application at 8ba14ae:

hotwire-native-android-demo.mp4

1. Click "Modal navigation"
   • (a) The modal opens
2. Click "Refresh navigation"
   • (a) The modal is dismissed
   • (b) The main view briefly shows "Navigation" in the title bar (as it should be)
   • (c) Then, the main view loads and shows the the "Modal Navigation" again (wrongly)

From debugging, I get the impression that loading the "Modal Navigation" (Step 2c) does not cause a turbo navigation, but does request the "Modal Navigation" endpoint from the server.

hotwire-native-ios

With the hotwire-native-ios demo, the app behaves as expected:

hotwire-native-ios.mp4

1. Click "Modal navigation"
   • (a) The modal opens
2. Click "Refresh navigation"
   • (a) The modal is dismissed
   • (b) The main view briefly shows the cached "Navigation" page
   • (c) The main view shows the refreshed "Navigation" page

We're willing to help, but will need some guidance. Thanks!

[noah44846]

We observe the same thing. Did you find a solution or workaround? Thank you very much!

We have found a quick fix that kinda solves the issue, but it hasn't been tested thoroughly yet.

We haven't had enough time to really look into this issue, but what we have found out is that the location set on the fragment that gets used by the session to create the visits is not mutable, it gets set once on instantiation of the fragment and after that it doesn't change even if the url in the web view changes. In simple cases, when we do a refresh, webView.refresh() gets called and everything works as intended. But in some other cases (for example a visit gets restored after a modal closes) the session uses the location value on the fragment which is the start location and not the up-to-date url in the webview which makes the fragment reset to the original location.

The quick fix works like this:

• we have overridden theonWebViewDetached and onStartAfterModalResult methods on our implementation of HotwireWebFragment to change the location (which is stored as an argument in the fragment) every time the webView detaches (when opening a modal, or advancing)
• this update of the location is skipped when it detaches after getting a result from a modal (when a modal gets dismissed) because in this case the active url in the webView is the url of the modal (I'm not sure why)
• the location attribute in HotwireWebFragmentDelegate is changed to a getter so that the location doesn't get copied on initialization

[fiedl]

Thank you very much for sharing your workaround!