This usually gets turned into a JavaScript visit and then handed over to the bridge, which begins the visit by calling visitLocationWithOptionsAndRestorationIdentifier.
However, when transforming this proposal JS -> Swift (for processing) and back to JS (for bridge consumption), visitProposed["options"]["response"]["redirected"] was being lost. This caused responseHTML to be ignored and a replace visit to be proposed instead.
By adding redirected to VisitResponse the behavior is now correct.
This reverts https://github.com/hotwired/turbo-ios/pull/155 which assumed that Turbo Native was using the same algorithm as Turbo to set flash notices.
When a redirection with a responseHTML would happen (e.g. a form submission), Turbo Native receives something like the following:
This usually gets turned into a JavaScript visit and then handed over to the bridge, which begins the visit by calling
visitLocationWithOptionsAndRestorationIdentifier
.However, when transforming this proposal JS -> Swift (for processing) and back to JS (for bridge consumption),
visitProposed["options"]["response"]["redirected"]
was being lost. This causedresponseHTML
to be ignored and a replace visit to be proposed instead.By adding
redirected
toVisitResponse
the behavior is now correct.