17

I have a web page that uses history.pushState with fragment identifiers (i.e. #Heading1) and jQuery's animate method to navigate within the document.

This is how I navigate to a location in the document:

$('nav a').click(function(e){
  e.preventDefault();
  var href = $(this).attr('href');
  history.pushState(null, null, href);
  $('#address').val(location.pathname + href);

  $('html, body').animate({
    'scrollTop': $(href).offset().top + 'px'
  });

Using Google Chrome on iOS, the address is updated as expected and the scroll animation works fine, but the back / forward buttons don't go to the identified tags.

I should note that when using the back / forward buttons, the URL in the address bar is changed. It just doesn't go to the identified tag.

I've only seen this problem using Google Chrome on iOS; both iPhone and iPad.

I've created a Pen at CodePen with a subset of my code that should demonstrate the problem: http://codepen.io/Ghodmode/pen/YqKGga

Update:
I've updated my pen to make it a little easier to test on an iPhone / iPad. It's probably also better to use the debug view: http://s.codepen.io/Ghodmode/debug/YqKGga

Update 2:
I've created another page at CodePen that should demonstrate the problem. This time, without jQuery: http://s.codepen.io/Ghodmode/debug/jqOqpq

I haven't been able to test this yet because I don't have direct access to iPhone / iPad, but I really don't think the problem has anything to do with jQuery.

It works fine on:

  • Safari on iPhone / iPad
  • Google Chrome on Android
  • Mozilla Firefox on Android
  • Google Chrome on Windows
  • Mozilla Firefox on Windows
  • Internet Explorer on Windows

I should probably note that I don't personally have any iOS devices to test this on, but I do have a reliable tester sending me videos and screenshots of any problems.

Since the animation works as expected, It doesn't seem like a jQuery problem.

Vince
  • 3,962
  • 3
  • 33
  • 58
  • I can't seem to find anything substantial on this, but I've switched from searching for _chrome ios hashchange_ to _ios webview hashchange_ since Chrome on iOS is just a UI wrapped around UIWebView. – Vince Feb 26 '16 at 12:07
  • 3
    [This Chromium bug report](https://bugs.chromium.org/p/chromium/issues/detail?id=559122) seems to confirm that Chrome on iOS doesn't fire the `hashchange` event when the back button is clicked, but I can't imagine how so few people have noticed this. – Vince Feb 26 '16 at 12:10
  • Any update on this ? A year later and I see same problem, cannot manipulate history (/ back button) using Google Chrome on iOS, works on anything else including Safari on iOS. – adrianTNT Feb 21 '17 at 00:57
  • @adrianTNT No update from me. I don't even remember this problem. The bug report I linked to says that the problem was fixed in a release that would've been available in late January 2016, but that doesn't seem to be the case. There's a chance that the device you're testing with hasn't been updated but that would also means that a large portion of your target audience for the page / app hasn't updated. I don't think there's a fix for this one. – Vince Feb 21 '17 at 03:51
  • I am getting this problem on iPhone SE and iPhone 7 iOS updated and latest Google Chrome. On Safari and all others it works OK. – adrianTNT Feb 23 '17 at 14:19

1 Answers1

1

iOS has a fair few bug with the HTML5 History API.

Have you tried:

window.addEventListener("popstate", function(e) {
    window.location.href = location.href;
});

This plugin may be of some use (even for background reading) History.js. It solves the cross-browser compatibility problems and also provides an optional HTML4 hash fallback if you'd like

Oam Psy
  • 8,555
  • 32
  • 93
  • 157