Incompatible with Chrome for iOS

[sstephenson]

There are some pushState-related differences from Mobile Safari in Chrome for iOS that cause Turbolinks not to work. Here's what I've found:

1. rememberInitialPage runs on the first call to visit in Mobile Safari, but in Chrome for iOS it runs as soon as the page loads.
2. In Mobile Safari, the window.history.state access in rememberCurrentState reflects the state that was set in the previous call to replaceState in rememberCurrentUrl. In Chrome for iOS, window.history.state is null in rememberCurrentState, so currentState is null too.
3. Because currentState is null in Chrome for iOS on the first call to visit, cacheCurrentPage fails. If you explicitly call Turbolinks.visit, the end result is the page never loads. If you click a link, it will fall back to a full page load.

[sstephenson]

Oh, and good luck with this one. Chrome provides essentially no debugging tools aside from alert.

[davydotcom]

Oh, this one is going to be just awesome. Since Chrome is simply using a UIWebView control they may be using some interesting js hacks to accomplish a true browser feel in the first place.

[davydotcom]

have an idea that might fix this. I know Chrome for iOS is a WebView wrapper. usually the only way to get event hooks out to native Objective C is to use urls and catch them in the delegate for a UIWebview. It may be possible to fix this if we restrict turbolinks to only fire on links that have no protocol defined or have http or https ?

[rahearn]

FWIW, I tested a site I wrote that uses turbolinks 0.6.1 today in Chrome for iOS and it seems to work fine.

[davydotcom]

Sweet, is it actually working or doing its graceful fallback?

On Wednesday, December 19, 2012, Ryan Ahearn wrote:

FWIW, I tested a site I wrote that uses turbolinks 0.6.1 today in Chrome for iOS and it seems to work fine.

— Reply to this email directly or view it on GitHubhttps://github.com/rails/turbolinks/issues/82#issuecomment-11535191.

[rahearn]

I'm not actually sure. It's not falling back to a full page reload as there's only one request for the page. Is there a way to tell if its working based on production logs?

On Wednesday, December 19, 2012 at 10:59 AM, David Estes wrote:

Sweet, is it actually working or doing its graceful fallback?

On Wednesday, December 19, 2012, Ryan Ahearn wrote:

FWIW, I tested a site I wrote that uses turbolinks 0.6.1 today in Chrome
for iOS and it seems to work fine.

—
Reply to this email directly or view it on GitHubhttps://github.com/rails/turbolinks/issues/82#issuecomment-11535191.

— Reply to this email directly or view it on GitHub (https://github.com/rails/turbolinks/issues/82#issuecomment-11535250).

[davydotcom]

If its not doing a full reload than yup it's working. Awesome... @dhh I think we can close this

On Wednesday, December 19, 2012, Ryan Ahearn wrote:

I'm not actually sure. It's not falling back to a full page reload as there's only one request for the page. Is there a way to tell if its working based on production logs?

On Wednesday, December 19, 2012 at 10:59 AM, David Estes wrote:

Sweet, is it actually working or doing its graceful fallback?

On Wednesday, December 19, 2012, Ryan Ahearn wrote:

FWIW, I tested a site I wrote that uses turbolinks 0.6.1 today in Chrome for iOS and it seems to work fine.

— Reply to this email directly or view it on GitHub< https://github.com/rails/turbolinks/issues/82#issuecomment-11535191>.

— Reply to this email directly or view it on GitHub ( https://github.com/rails/turbolinks/issues/82#issuecomment-11535250).

— Reply to this email directly or view it on GitHubhttps://github.com/rails/turbolinks/issues/82#issuecomment-11535371.

[dhh]

Sam, can you confirm if all is well?

[davydotcom]

This may be related to using the new Date().getTime instead of window.history.length patch

[sstephenson]

Nope, just tried the latest Turbolinks on Basecamp and it's still not working in Chrome.

[rahearn]

Yes, I spoke too soon. I was expecting to see either a double request or a total lack of navigation for breakage. I am seeing problem 2 in the initial bug report, which is cause the turbolinks code to silently crash and the click event to be handled by the anchor tag. Never thought I'd be enjoying the benefits of graceful degradation in a fully js enabled browser.

Turbolinks is behaving properly in the Switch browser for iOS, so this might just be a bug in Chrome itself, and not a problem for every UIWebView based browser.

[dhh]

Until this issue is fixed, we should detect Chrome for iOS as an incompatible browser, and just not activate turbolinks. Could someone make a pull request for that?

[davydotcom]

i thought it was gracefully falling back already. am I wrong on that assumption?

[dhh]

Yeah, we have custom code to detect and fallback in BCX right now:

if navigator.userAgent.match /CriOS\//
  # Temporary workaround for Turbolinks' incompatibility with Chrome iOS
  Turbolinks.visit = (url) ->
    window.location = url
  bcx.on document, "click", "a", (event) ->
    window.location = @href
    event.preventDefault()

[davydotcom]

hah ok. one sec.

[davydotcom]

@dhh there you go issue #161 pull has a check on initializeTurbolinks if browserIsntCriOS

[liamzebedee]

Hey all, has this been closed permanently as a non-fixable issue?

[liamzebedee]

Anyone have any idea as to the root cause? Push.js from the Ratchet framework is able to function in Chrome on iOS (by simply using replaceState), could someone explain why Ratchet needs specific access to window.history.state? I'd be willing to give it a try to fix, Turbolinks is much better :)

[javan]

It's worth revisiting the issues Sam outlined in his initial report. If it's working now in the latest Chrome for iOS, we can scope the browser check to older versions.

[brendon]

Is this bug/problem/workaround present in Turbolinks 5?