There's a potential bug in Turbo-iOS when it comes to submitting forms and rendering the response HTML.

I notice the following flow when submitting a form in Turbo iOS:

1. The form is submitted.
2. The server issues a redirect upon successful form response.
3. The redirect is followed, and the response is returned.
4. The WebView bridge is alerted to a "Visit Proposed" event containing the response HTML.
5. You're free to route the proposal as desired, usually ended with calling the "window.turboNative.visitLocationWithOptionsAndRestorationIdentifier" with the response HTML.

The problem is, calling "window.turboNative.visitLocationWithOptionsAndRestorationIdentifier" containing response HTML returns the exact same page, completely ignoring the response HTML.

If you try this in the demo app, it will work the first time and the first time only. Subsequent form submissions will continue to return the same page over and over again. This is because of a "Back Navigation" bug, where submitting the form the first time, the app thinks you hit the back button, and issues another get request.

Walking through step by step in the Demo app, using Proxyman to see requests/responses to/from the server:

1. Run the app
2. Tap "Load a web page modally"
3. Submit the form. Proxyman shows two get requests, the first from the redirect, the second from the above mentioned "Back Navigation" bug: The rendered screen is "correct" only because of the second get request.

4. Hit the back button.

5. Tap "Load a web page modally" again.

6. Submit the form. Proxyman now shows one get request, as expected. However, the response HTML was ignored. This can be seen by comparing the time stamps of the response HTML with the time stamp rendered on screen:

Walking through the "Back Navigation" bug:

1. Run the app
2. Tap "Load a web page modally"
3. Place breakpoints on line 207 of "Session.swift" and line 47 of "Visit.swift".
4. Submit the form.
5. Breakpoint: The first time and first time only, a "visit did complete" message comes from the ScriptMessageHandler, setting the state of the Visit to complete. I have no idea why this event is sent, but it's the reason for the Back Navigation bug. Hit continue.
6. Breakpoint Session's visitableViewWillAppear activates, and ends up in the "Navigating Backward" path, issuing another visit (GET request 2). It is this second GET request that gives the appearance of "correct" behavior when submitting the form the first time.

Subsequent form submissions skip step 5, so on visitableViewWillAppear, it ends up in the "Navigating Forward" path, issuing only one GET request as it should. But because the response HTML is ignored by Turbo, it re-renders the same screen again and again. Refreshing the page renders the correct response.

I believe this is bug in turbo.js, but I can't say for sure because I can't set breakpoints in the javascript code in Xcode. 😢 I need to do more research into how Turbo itself works.

My current workaround is to set the response HTML to nil before passing the proposal to "window.turboNative.visitLocationWithOptionsAndRestorationIdentifier". This seems to trick Turbo into not knowing that the request came a redirected form submission, so it issues another GET request. Submitting two GET requests per form submission is not ideal, though.

This is an intermediary solution for #50.

In summary, WKWebView can terminate under certain circumstances when in the background. When a Turbo-powered app is re-opened after this occurs the app can be left in a weird state.

This PR adds a new delegate callback, sessionWebViewProcessDidTerminate(_:), that developers can hook into to do what they see fit. @tony42, for example, is resetting the state of their app. I'm following that same approach.

I'm not sure if/how this can be handled better inside of this library short of iOS 16 fixing the issue entirely. So this feels like the next best approach as it puts the power back in the developer's hands.

The current debug logging is insufficient to understand what's going on behind the scenes and investigate issues. This is a step in the right direction.

Previous log output:

2022-06-30 03:29:06 +0000 - [ColdBootVisit] startVisit()
2022-06-30 03:29:07 +0000 - [Bridge] ← pageLoaded
2022-06-30 03:29:09 +0000 - [Bridge] ← visitProposed
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] startVisit()
2022-06-30 03:29:09 +0000 - [Bridge] → window.turboNative.visitLocationWithOptionsAndRestorationIdentifier
2022-06-30 03:29:09 +0000 - [Bridge] ← visitStarted
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didStartVisitWithIdentifier:hasCachedSnapshot:)
2022-06-30 03:29:09 +0000 - [Bridge] ← visitRequestStarted
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didStartRequestForVisitWithIdentifier:date:)
2022-06-30 03:29:09 +0000 - [Bridge] = window.turboNative.visitLocationWithOptionsAndRestorationIdentifier evaluation complete
2022-06-30 03:29:09 +0000 - [Bridge] ← visitRequestFinished
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didFinishRequestForVisitWithIdentifier:date:)
2022-06-30 03:29:09 +0000 - [Bridge] ← visitRequestCompleted
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didCompleteRequestForVisitWithIdentifier:)
2022-06-30 03:29:09 +0000 - [Bridge] ← visitCompleted
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didCompleteVisitWithIdentifier:restorationIdentifier:)
2022-06-30 03:29:09 +0000 - [Bridge] ← visitRendered
2022-06-30 03:29:09 +0000 - [JavaScriptVisit] webView(_:didRenderForVisitWithIdentifier:)
2022-06-30 03:29:11 +0000 - [JavaScriptVisit] startVisit()
2022-06-30 03:29:11 +0000 - [Bridge] → window.turboNative.visitLocationWithOptionsAndRestorationIdentifier
2022-06-30 03:29:11 +0000 - [Bridge] ← visitStarted
2022-06-30 03:29:11 +0000 - [JavaScriptVisit] webView(_:didStartVisitWithIdentifier:hasCachedSnapshot:)
2022-06-30 03:29:11 +0000 - [Bridge] = window.turboNative.visitLocationWithOptionsAndRestorationIdentifier evaluation complete
2022-06-30 03:29:11 +0000 - [Bridge] ← visitCompleted
2022-06-30 03:29:11 +0000 - [JavaScriptVisit] webView(_:didCompleteVisitWithIdentifier:restorationIdentifier:)
2022-06-30 03:29:11 +0000 - [Bridge] ← visitRendered
2022-06-30 03:29:11 +0000 - [JavaScriptVisit] webView(_:didRenderForVisitWithIdentifier:)

New log output:

2022-06-30 03:30:11 +0000 [Session] visit ["reload": false, "location": https://turbo-native-demo.glitch.me, "options": Turbo.VisitOptions(action: Turbo.VisitAction.replace, response: nil)]
2022-06-30 03:30:11 +0000 [ColdBootVisit] startVisit https://turbo-native-demo.glitch.me [:]
2022-06-30 03:30:12 +0000 [Bridge] ← pageLoaded ["timestamp": 1656559812055, "restorationIdentifier": 42918dac-ca08-4d87-ae88-d866b21e9e14] [:]
2022-06-30 03:30:12 +0000 [ColdBootVisit] completeVisit https://turbo-native-demo.glitch.me [:]
2022-06-30 03:30:18 +0000 [Bridge] ← visitProposed ["location": https://turbo-native-demo.glitch.me/one, "options": {
    action = advance;
}, "timestamp": 1656559818238] [:]
2022-06-30 03:30:18 +0000 [Session] visit ["options": Turbo.VisitOptions(action: Turbo.VisitAction.advance, response: nil), "location": https://turbo-native-demo.glitch.me/one, "reload": false]
2022-06-30 03:30:18 +0000 [JavascriptVisit] startVisit https://turbo-native-demo.glitch.me/one [:]
2022-06-30 03:30:18 +0000 [Bridge] → window.turboNative.visitLocationWithOptionsAndRestorationIdentifier [Optional("https://turbo-native-demo.glitch.me/one"), Optional({
    action = advance;
}), nil] [:]
2022-06-30 03:30:18 +0000 [Bridge] ← visitStarted ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "hasCachedSnapshot": 0, "timestamp": 1656559818246] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didStartVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c", "hasCachedSnapshot": false]
2022-06-30 03:30:18 +0000 [Bridge] ← visitRequestStarted ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "timestamp": 1656559818248] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didFinishRequestForVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c", "date": 2022-06-30 03:30:18 +0000]
2022-06-30 03:30:18 +0000 [Bridge] = window.turboNative.visitLocationWithOptionsAndRestorationIdentifier evaluation complete [:]
2022-06-30 03:30:18 +0000 [Bridge] ← visitRequestCompleted ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "timestamp": 1656559818344] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didCompleteRequestForVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c"]
2022-06-30 03:30:18 +0000 [Bridge] ← visitRequestFinished ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "timestamp": 1656559818344] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didFinishRequestForVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c", "date": 2022-06-30 03:30:18 +0000]
2022-06-30 03:30:18 +0000 [Bridge] ← visitCompleted ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "restorationIdentifier": 4904de48-531e-42ec-b9e2-6ec8304108a9, "timestamp": 1656559818347] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didCompleteVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c", "restorationIdentifier": "4904de48-531e-42ec-b9e2-6ec8304108a9"]
2022-06-30 03:30:18 +0000 [Bridge] ← visitRendered ["identifier": 6cd858b3-5a0c-4695-a5b0-48597a97ea1c, "timestamp": 1656559818366] [:]
2022-06-30 03:30:18 +0000 [JavascriptVisit] didRenderForVisitWithIdentifier https://turbo-native-demo.glitch.me/one ["identifier": "6cd858b3-5a0c-4695-a5b0-48597a97ea1c"]
2022-06-30 03:30:20 +0000 [Session] visit ["location": https://turbo-native-demo.glitch.me, "options": Turbo.VisitOptions(action: Turbo.VisitAction.restore, response: nil), "reload": false]
2022-06-30 03:30:20 +0000 [JavascriptVisit] startVisit https://turbo-native-demo.glitch.me [:]
2022-06-30 03:30:20 +0000 [Bridge] → window.turboNative.visitLocationWithOptionsAndRestorationIdentifier [Optional("https://turbo-native-demo.glitch.me"), Optional({
    action = restore;
}), Optional("42918dac-ca08-4d87-ae88-d866b21e9e14")] [:]
2022-06-30 03:30:20 +0000 [Bridge] ← visitStarted ["identifier": a966548e-8e36-4b39-a039-e4a03ec27734, "hasCachedSnapshot": 1, "timestamp": 1656559820532] [:]
2022-06-30 03:30:20 +0000 [JavascriptVisit] didStartVisitWithIdentifier https://turbo-native-demo.glitch.me ["hasCachedSnapshot": true, "identifier": "a966548e-8e36-4b39-a039-e4a03ec27734"]
2022-06-30 03:30:20 +0000 [Bridge] = window.turboNative.visitLocationWithOptionsAndRestorationIdentifier evaluation complete [:]
2022-06-30 03:30:20 +0000 [Bridge] ← visitCompleted ["restorationIdentifier": 42918dac-ca08-4d87-ae88-d866b21e9e14, "identifier": a966548e-8e36-4b39-a039-e4a03ec27734, "timestamp": 1656559820533] [:]
2022-06-30 03:30:20 +0000 [JavascriptVisit] didCompleteVisitWithIdentifier https://turbo-native-demo.glitch.me ["restorationIdentifier": "42918dac-ca08-4d87-ae88-d866b21e9e14", "identifier": "a966548e-8e36-4b39-a039-e4a03ec27734"]
2022-06-30 03:30:20 +0000 [Bridge] ← visitRendered ["identifier": a966548e-8e36-4b39-a039-e4a03ec27734, "timestamp": 1656559820549] [:]
2022-06-30 03:30:20 +0000 [JavascriptVisit] didRenderForVisitWithIdentifier https://turbo-native-demo.glitch.me ["identifier": "a966548e-8e36-4b39-a039-e4a03ec27734"]

Does turbo-ios have inbuilt APIs to request access to Camera or GPS? Or is there an expectation that users of turbo-ios will have to write additional swift code to handle such requests?

The latest importmap-rails (included in Rails 7 rc1) includes es-module-shims.js version 1.3.5. This latter library creates blob URLs that the Turbo Demo app tries to visit. This causes errors with http status code 0.

One current workaround is to fork importmap-rails and downgrade es-module-shims.js to version 1.2.0 so the backend is serving this downgraded shim to the Demo app.

I don't think this relates to Turbolinks but it likely affects all apps which run it (or some of them at leats).

When our app is in background for some time and one opens a bunch of other apps so that the phone is low on memory, our app will get to a weird state the next time you open it. No content is shown in the webview and there is a bunch of messages in the XCode console. My understanding is that WebView runs a service which gets killed by the OS and is vital for WebView to run properly.

I do have a workaround which requires a slight change in the Turbo library. I changed the method webViewWebContentProcessDidTerminate() in Session.swift to post a notification when the webview process terminates:

public func webViewWebContentProcessDidTerminate(_ webView: WKWebView) {
        debugLog("[Session] webViewWebContentProcessDidTerminate")
        NotificationCenter.default.post(name: Notification.Name("webViewWebContentProcessDidTerminate"), object: nil)
    }

Then I basically restart our App with a fresh WebView. It's not ideal as I loose the app state but it's the best I could come up with.

I'd like to ask two things:

• do you have the same issue with other Turbo apps or is it just us?
• would it be possible to add my change to the official Turbo code? I think it might be useful for other developers as well.

I've found this forum post which is likely exactly the issue we have:

https://developer.apple.com/forums/thread/684843

Please note that this is not happening on iOS 14.

Thanks a lot

Tony

We noticed this issue because we'd like to access the TurboNavigationController inside of a native modal in order to invoke some navigation from there.

To reproduce the issue you simply need to add "presentation": "modal", in line 21 of path-configuration.json: https://github.com/hotwired/turbo-ios/blob/2277f7dcd52c3f8eac735980166e64bd5745272b/Demo/path-configuration.json#L21

After that, when you run the demo, you can click on "intercept with a native view" and click on one of the rows. Now the app will crash.

It seems as if the navigationController in this case is simply an instance of UINavigationController and not of TurboNavigationController, so the forced cast lets the app crash. I think this is caused by this line here: https://github.com/hotwired/turbo-ios/blob/2277f7dcd52c3f8eac735980166e64bd5745272b/Demo/Navigation/TurboNavigationController.swift#L89

So the questions are:

1. Is this a bug, or intended behavior?
2. If it's intended, how do we achieve navigation from within a native modal instead?

N. b. I tested the same thing with the android demo where it doesn't crash, so I suspect this is indeed a bug.

The end of the Authorization doc mentions getting cookies alongside an OAuth response.

For HEY, we have a slightly different approach. We get the cookies back along with our initial OAuth request and set those cookies directly to the web view and global cookie stores.

First, can you elaborate a bit more on how that's possible with Rails? This request is coming from a new client, so it shouldn't have any existing or shared session/cookies. Are they created fresh? If so, how?

Second, am I wrong to assume that the access token request should be hitting an API-like controller? This will be a request without a CSRF token, so no protection can be added there. But if I work with, for example, ActionController::API, then I don't even have access to the cookies.

I've spent a while on this and feel like I'm missing something obvious. But I'm kind of lost as to how this all lines up. Any help would be greatly appreciated! Thanks in advance.

I've found Turbo logging to be quite verbose and get in the way of my application logs. This PR lets the developer disable Turbo logging by adding the disableTurboLog launch argument to their scheme.

This could have been an environment variable, but the double negative get's weird, and those are parsed as strings. If we wanted to add logging levels then environment variables are the better choice.

In brief: After visiting a GET request that responded with a redirect, the location.pathname of a turbo-ios webview is the requested path rather than the redirect-target path. This is different from how it is handled in Chrome, Safari, and Mobile Safari where the resulting location.pathname is the ultimate redirect-target path.

Please see: https://github.com/johnmaxwell/turbo-native-demo/pull/1/files

This fork and patch to the hotwired/turbo-native-demo demo app adds a /get-redirect GET route that simply redirects (302) to /one and an index link for it.

☝️Tapping the "Go through a redirect" on a desktop browser (Chrome or Safari) takes the browser to /one as expected, showing both the page content and updating the browser URL.

☝️ In the context of turbo-ios, the browser is shown the content of /one as expected, but the location.pathname remains on /get-redirect

Is this expected behavior or a known issue?

☝️In our production Rails app, we have a notification tray that contains a variety of types of notifications, each resolving to a different target URL. In that tray, we link not to the target URL, but to a notification URL -- e.g. /notifications/123 -- where the user's interaction is logged before forwarding them to the final target -- e.g. /final-target

In attempting to package our Rails app in a turbo-ios project, we have noticed that the app location.pathname hangs on /notification/123 . For subsequent link clicks, the referrer is then passed as /notification/123 instead of /final-target.

This gif demonstrates the bug:

To replicate, using https://github.com/hotwired/turbo-native-demo

// index.ejs

  <form method="post" action="/redirect">
    <button type="submit">Submit Form and redirect to another page</button>
  </form>

// server.js

app.post("/redirect", (request, response) => {
  response.redirect("/one")
})

Or click here to see the changes: https://github.com/hotwired/turbo-native-demo/compare/main...ghiculescu:duplicate-page-replica (if you'd like redirect behavior in the demo, I can tidy up the UI and make a PR - but that's not the issue here :))

When you click on the button:

• The POST request is made and returns a 302
• Turbo.js catches the 302 and makes a GET to /one
• Turbo-native's didProposeVisit is called with /one as the desired URL. session.visit(/one) gets called. And another GET to /one is made.

You can see this in the demo server logs:

Sat Jan 09 2021 17:35:23 GMT-0700 (Mountain Standard Time) -- POST /redirect
Sat Jan 09 2021 17:35:23 GMT-0700 (Mountain Standard Time) -- GET /one
Sat Jan 09 2021 17:35:23 GMT-0700 (Mountain Standard Time) -- GET /one

As well as the doubled up requests in Safari's inspector. I would expect only a single GET /one.

This isn't too bad in this case, but where it gets really problematic is if the POST request sets a flash (in Rails). For example:

def create
  redirect_to some_path, alert: "something happened"
end

In this case the flash will be consumed by the first GET request, and will not appear in the second one. So from the app's perspective no flash message is shown (but if you do exactly the same behavior through a web browser, you do see a flash).

The proposed change adds support for a custom color (light/dark) from the HTML attribute, which can be helpful.

<!doctype html>
<html> 

<head>
  <meta name="theme-color" content="#f5f7fa" media="(prefers-color-scheme: light)">
  <meta name="theme-color" content="#232730" media="(prefers-color-scheme: dark)">
</head>

...

This can be a convenient and intuitive way to style an element, especially for users unfamiliar with Swift. Also, this ensures that the colors will always be up-to-date and the same as in the PWA version.

In the end, this will increase the usability for those who start cloning a Demo project.

I noticed that the description of the home page requires the rails package. Although, it really only needs @hotwired/turbo. I took the formatting from the Turbo documentation

Hey, i want to make an initial application loading screen (Beautiful picture).

I've been to change the first screen and put its change after N seconds. But this seems like a very bad solution to me. Because after N seconds it will show the Turbo screen with page loading.

I wanted very much that the display of the first image would be tied to the loading of the page on the network. Since I can't just add the image to the screen with a visual builder. I created a very simple controller:

import UIKit

class SplashController: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        navigationController?.setNavigationBarHidden(true, animated: true)
        
        
        let image = UIImage(named: "Splash")
        let imageView = UIImageView(image: image)
        
        imageView.frame = UIScreen.main.bounds
        self.view.addSubview(imageView)
    }

}

But where to return it correctly and link it to the content download in the demo? I would be grateful for any help

No CSS loaded sometimes after a user returns to the App.

You guys have any clue where to search for this? It happens on iOS and on Android and it occur randomly as it seems.

I have some functions on returning to the app, displayed here, maybe something is wrong here?

Is it maybe a package issue?

Cheers, Chris

Hello, I have a calendar file that is downloading:

<a href="https://example.com/user.ics" download="calendar">
    Download
</a>

When you click on it, the application opens the browser with a blank page and only then offers to add values ​​to the ios calendar.

https://user-images.githubusercontent.com/5102591/193480123-eae5406b-6718-4657-ab27-ca43105d293e.MOV

Can anyone suggest how to avoid opening the browser and staying in the application?