# Understanding Turbo 8 morphing fallback

**URL:** <https://discuss.hotwired.dev/t/understanding-turbo-8-morphing-fallback/5527>\
**Category:** General\
**Created:** [December 29, 2023, 11:30pm UTC](https://discuss.hotwired.dev/t/understanding-turbo-8-morphing-fallback/5527 "2023-12-29T23:30:05Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![krschacht](https://yyz1.discourse-cdn.com/flex027/user_avatar/discuss.hotwired.dev/krschacht/32/3570_2.png) [@krschacht](https://discuss.hotwired.dev/u/krschacht)\
**Post date:** [December 29, 2023, 11:30pm UTC](https://discuss.hotwired.dev/t/understanding-turbo-8-morphing-fallback/5527/1 "2023-12-29T23:30:05Z")

</div>

I am trying to understand the inner workings for Turbo 8’s new morphing feature. My specific question is: what determines when morphing will fall back to a full page refresh rather than doing the morph? And which section of the rails turbo code is this taking place in?

My details:

I have setup this demo project: [GitHub - basecamp/turbo-8-morphing-demo](https://github.com/basecamp/turbo-8-morphing-demo) it works fully, e.g. two browsers open, one making changes, the other one refreshes just the needed dom elements and holds the scroll position.

However, I then try opening another browser in an embedded mobile web view. This mobile web view works, however it does not morph. Every time I make a change in my desktop browser, the mobile webview detects this change and refreshes (so clearly the socket is connected) but it does a full page refresh rather than morphing the page.

I tried opening in mobile Safari and it properly morphs there.

My theory is that my mobile webview may be lacking a user agent, or has some other characteristic, which is causing Turbo 8 to decide to fallback to a full page refresh. But I haven’t been able to find this specific area of logic in within the turbo-rails repo to try and debug this myself.