Unexpected behaviour with `clear_all` and `replace_root`

[leonvogt]

I've experienced some unexpected behavior where clear_all and replace_root lead to more requests than expected.

Related Issues on the Android side: hotwired/hotwire-native-android#115

Replace root

Steps to reproduce:

1. Ensure the Demo app has the following path configuration snippet (should be included by default):

{
  "patterns": [
     "^/$"
  ],
  "properties": {
     "presentation": "replace_root"
  }
},

2. Update the server.js file of the Demo Server like this:

app.get("/two", (request, response) => {
-  response.render("two", { title: "Push or Replace?", action: request.query.action })
+  response.redirect("/")
})

3. Navigate to /one (title: "Navigate to another page")
4. Navigate to /two (title: "Advance to another webpage")

Expected Server Logs:

GET /one
GET /two
GET /

Actual Server Logs:

GET /one
GET /two
GET /
GET /
GET /

The routing documentation states, replace_root will:

Dismiss if modal screen then
Pop to root then
Replace root screen on main stack

The root screen route is loaded three times. With the exact same setup, Hotwire Native Android calls / twice.
My expectation was that the root screen would only be loaded once.

Clear all

There are two things I don't quite understand regarding clear_all. Here are the steps I followed to replicate the issue:
(Do not use the server code from the previous example)

1. Add the following to the path configuration to use /two as a clear_all route:

{
  "patterns": [
    "^/two$"
  ],
  "properties": {
    "presentation": "clear_all"
  }
},

2. Navigate to /one
3. Navigate to /two

Expected Server Logs:

GET /one
GET /two
GET /

Actual Server Logs:

GET /one
GET /two

According to the documentation, clear_all will:

Dismiss if modal screen then
Pop to root then
Refresh root screen on main stack

Maybe I misunderstood what "refresh the root screen" means. I assumed it meant that after popping all screens, the app would load the root screen again.
Again, this might be intended behavior, but I wanted to mention it here for clarification.

Redirecting to a clear_all route

1. Like before, add the following to the path configuration, to use /two as a clear_all route:

{
  "patterns": [
    "^/two$"
  ],
  "properties": {
    "presentation": "clear_all"
  }
},

2. Update the server.js to redirect to /two:

app.get("/one", (request, response) => {
-  response.render("one", { title: "How’d You Get Here?" })
+  response.redirect("/two")
})

3. Navigate to /one

Expected Server Logs:

GET /one
GET /two
GET /

Actual Server Logs:

GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two
GET /one
GET /two

I'm not sure why this is happening. Is it possible that clear_all isn't intended to be used with redirects?
My guess is that clear_all is only meant for a dedicated route to which we explicitly navigate, rather than redirecting to it.
I wanted to mention this here in case it's not the intended behavior.

To break it down:

1. 3 requests to the root screen when using replace_root
2. No request to the root screen when using clear_all
3. Loop when redirecting to a clear_all route

I'm happy to help figure this out if you could clarify which behavior is intended and which is not.
Thanks!

---

Edit: I've tested it with v1.2.0 and could reproduce the same behaviour.

[iamjohnford]

I've run into a similar issue and it appears to happen without needing to change any demo app code.

To reproduce:

• Open iOS Demo app with hotwire-native-ios v1.1.3
• Point Demo app to run locally against turbo-native-demo
• Launch iOS app and click on "Follow a redirect"

Expected output in server console:

GET /follow
GET /redirected

Actual output in server console:

GET /follow
GET /redirected
GET /redirected

It's loading /redirected twice and appears to display the 2nd redirect in the webview. This has caused issues with our Rails app since we have flash messages that are expected and they're not displayed after the 2nd page load.

Side note: I sometimes add <meta name="turbo-prefetch" content="false"> to the turbo-native-demo app since it can prefetch an extra time when tapping on a link in the simulator and I don't want any false positives.

[iamjohnford]

I just tested this again using main and v1.2.0 and I'm seeing the same issue as above where a redirect creates an additional redirect.

To reproduce:

1. Point demo to local Rails app
2. Add the following in the <head> of app/views/layouts/application.html.erb to make sure there are no extra taps getting registered from the prefetch or long presses showing the preview.

  <meta name="turbo-prefetch" content="false">
  <style>
    html {
        -webkit-touch-callout: none;
    }
  </style>

3. Click on the "Redirect" link in the demo

I'm seeing the following output in the rails console in this order (extra items removed for brevity):

Started GET "/navigation/redirect"
Completed 302 Found
Started GET "/navigation/redirected"
Completed 200 OK
Started GET "/navigation/redirect"
Started GET "/navigation/redirected"
Completed 302 Found
Completed 200 OK

[glennfu]

This is still an issue in real applications trying to use hotwire-native-ios. I haven't noticed the same problem in hotwire-native-android.

Since it's been reproducible in the demo I hope it will be easy to track down and solve.

[iamjohnford]

Just tested with the steps above on v1.2.2 and can still recreate the issue. I've removed some of the extra console output to make it easier to read.

Fresh load of app and clicking "Redirect"

Started GET "/navigation/redirect"
Processing by NavigationsController#redirect as HTML
Redirected to http://localhost:3000/navigation/redirected
Completed 302 Found

Started GET "/navigation/redirected"
Processing by NavigationsController#redirected as HTML
Completed 200 OK

Started GET "/navigation/redirect"
Started GET "/navigation/redirected"
Processing by NavigationsController#redirect as HTML
Processing by NavigationsController#redirected as HTML
Redirected to http://localhost:3000/navigation/redirected
Completed 302 Found
Completed 200 OK

Go back and click "Redirect" a second time and it has one less Started GET "/navigation/redirected" at the end

Started GET "/navigation/redirect"
Processing by NavigationsController#redirect as HTML
Redirected to http://localhost:3000/navigation/redirected
Completed 302 Found

Started GET "/navigation/redirected"
Processing by NavigationsController#redirected as HTML
Completed 200 OK

Started GET "/navigation/redirect"
Processing by NavigationsController#redirect as HTML
Redirected to http://localhost:3000/navigation/redirected
Completed 302 Found

It still appears that extra calls are being made when there's a redirect.

[iamjohnford]

@joemasilotti @williamkennedy Just like my other issue, is there any other information I can provide to help with this one? It seemed like a bug so I added it to this existing issue. Thanks!

[joemasilotti]

Thanks for reporting this! It looks like the second set of visits is occurring because of the following:

extension Session: VisitableDelegate {
    // ...

    public func visitableViewDidAppear(_ visitable: Visitable) {
        if let currentVisit = currentVisit, visitable === currentVisit.visitable {
            // Appearing after successful navigation
            completeNavigationForCurrentVisit()
            if currentVisit.state != .failed {
                activateVisitable(visitable)
            }
        } else if let topmostVisit = topmostVisit, visitable === topmostVisit.visitable && topmostVisit.state == .completed {
            // Reappearing after canceled navigation
            visit(visitable, action: .restore) // <-- Getting called.
        }
    }

    // ...
}

Because the Visitable hasn't actually completed its redirected visit here, it's visiting /redirect a second time. Which then causes an additional request to /redirected.

Interestingly enough, Hotwire Native thinks the reason this screen appeared is that a modal was dismissed. Which is very clearly not true!

open class VisitableViewController: UIViewController, Visitable {
    // ...

    override open func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        if appearReason == .tabSelected { return } // <-- appearReason == .revealedByModalDismiss
        visitableDelegate?.visitableViewDidAppear(self)
    }

    // ...
}

This is occurring because we are always calling dismiss(animated:), even when there is no modal view controller to dismiss. Safe because it no-ops, but it does mess with our state.

I need to dig into this more - thanks again for reporting!