ajax navigation problems on iOS/Android related to rel="external" #2521

ChristoDeluxe opened this Issue Sep 24, 2011 · 21 comments

5 participants


I now note a navigation flaw on iOS 4.3.5 (latest on both iPod and iPad) and Android's browser on OS 2.3.4 (Nexus One). It does not seem to happen on iOS 3.1.3, so maybe related to hashtag replacement?

I've confirmed this bug on recent "latest" versions including the build dated "Thu Sep 22 21:31:03 2011 -0400".

I've made a set of simple test pages to show this issue in action. Navigate to:

Here's the workflow:

1-go to the home page (which uses jQM)
2-click to another screen (also uses jQM)
3-click on item that links (rel="external") to an HTML file not using jQM
4-click back button to go to screen 2
5-click a "home" button on screen 2 that links (again rel="external") to home page (same page as step 1)
6-home page loads, but then the browser immediately transitions with "loading" indicator to the page from step 2

This all seems to be triggered by the link in step 3 being "external". If I only touch links that lead to other pages that use jQM and aren't "rel=external" links, then this doesn't seem to happen.

This bug doesn't seem to happen on Safari 5.1 and Firefox 6.0.2 on the desktop.


I just tested this on a few browsers and don't see the issue. Can you re-test?



Yes, I'm still seeing this; tested just now after clearing browser cache/history.

I see this problem reliably on these devices/platforms:

-iPod Touch running iOS 4.3.5 (8L1) in Safari
-iPad running iOS 4.3.5 (8L1) in Safari
-iOS simulator with iOS 4.3.2 (8H7) in Safari
-Nexus One stock browser running Android OS 2.3.6
-Android emulator with OS 2.2 and stock browser

I have not tested with iOS 5 beta releases. This problem does NOT seem to happen on desktop Safari or Firefox.

FYI, others are reporting the same, here on the jQM forum where I also reported this issue:


@jblas jblas was assigned Sep 27, 2011

Hi all -

Thanks for the details, we're taking a look now.


I can repro this on an iPad running 4.3.5. The problem does NOT happen with pushstate turned off:

$( document ).bind( "mobileinit", function() {
    $.mobile.pushStateEnabled = false;

Cc: @johnbender @scottjehl


@johnbender @scottjehl @toddparker

So it seems I can reproduce this problem with Windows Safari 5.0.5 (Desktop). What seems to be happening is that Safari is actually loading the homepage.html external link as an external document (as it should), but then it goes and fires a popstate event that contains some state object data from the previous document.

I think perhaps the fact that the previous document in the history list (homepage.html) is the same as the new/active document (homepage.html) is confusing Safari/Webkit.


... it's almost as if it is treating the document (homepage.html) as if the user did a window.history.back() from some other document.



I just did some testing in several browsers and they all handle the specific case of navigating to the same document while there are states on the history stack, differently. Some fire popstate events with the last active state, some don't. Some replace the current active state with the new document instance, others push a new history entry ... and of course all of this depends on the format of the URL being pushed (hash or no hash).

Is there some reason you need to link to your homepage.html with a rel="external" link, instead of just allowing the framework to navigate as it naturally would? If for some reason you MUST use rel="external" then I have to suggest turning off the pushstate support within the framework for your usage as I did above with a mobilinit callback.


I think @jblas's suggestion makes a lot of sense. Is is essential to use rel="external" and pushState given how inconsistent browser implementations are? Not sure we're going to be able to normalize this on our end so I'd lean towards closing as won't fix and documenting this.


Yes, in my case I don't need the little home button to actually be rel="external" -- I'd actually done that to work around bugs in earlier alpha/beta releases of jQM as a way to get a "clean slate" for navigation. I don't think any of those problems exist in the current betas, so I can remove that and use AJAX nav there.

I worry that there are more general use cases for this problem though, but I can't think of one off-hand that would be a common use case for people.

In my app, there will commonly be external links to user-provided HTML and/or other documents (PDF, Word, etc..), so the user will follow much of the workflow in my example, but the home button doesn't need to be that way, and I doubt any of the external content would ever contain links back into the jQM part of the web app, the user would normally use the back button to come back to a page "inside" the jQM app.


Seems like this is an issue, but it's on the browser makers to improve this because we've done what we can on our side. Reduced the priority but will leave this open. Thanks all!


Note: Issue #2623 seems to be a report of the same problem.

@johnbender johnbender was assigned Oct 6, 2011

I have come across the same issue and have had to revert to Beta3 because of this - where it does not happen. I have kept the pages that are being linked to as rel="external" because of wanting to enable Facebook Share and I know that we need to set Facebook head meta-tags in the page as served and cannot change or set these in the DOM. I note this behaviour on iOS Safari and Android Browser on 2.3. It does not happen on Desktop browsers, Chrome 14 (BTW the Ripple emulator makes no difference here) and Safari 5.0.5. I have tested with both a single and multiple JQM pages on the page that you are linking from and this makes no difference. I have $.mobile.ajaxEnabled = false; This is a showstopper for me as this is happening in the link between master and detail pages and I think a very common use case will be users going to a detail page and then using their back button to go back and then go to another detail page.

Just to note that the behaviour is slightly different as the steps are as follows, I will take your advice on whether this needs to be logged seperately.
1. Go to master page with multiple rel="external" links (links painted in by standard jquery DOM manipulation triggered by the pagecreate event)
2. Go to detail page through one of these links.
3. Click browser back to go back to master page.
4. Click on another rel="external" link (painted in by standard jquery DOM manipulation)
Expected: go to second detail page
Actual: Master page gets repainted without the links as pagecreate is not fired.




Have you tried disabling pushState? Anytime before document ready you can do the following:

$.mobile.pushStateEnabled = false;

This issue is directly related to our inclusion of the pushstate plugin so that should most likely work for you.



We're actually adding some more information to the docs as we speak, but the short story is that some browser implementations (including desktop browsers) implement the popstate event differently when linking externally and moving back to a page onto which state has already been pushed/replaced.

The reason the plugin is enabled by default is that hash navigation is fundamentally flawed in that using the hash we're dependent on javascript when the page isn't embedded which is inherently unreliable.


Added some details here:

If we can't normalize the browser behavior, is simply documenting why/when to disable the replaceState feature al we can do now to fix this issue? Should we close this?



I think we can safetly close this with your documentation additions.


We'll take your recommendation into consideration.

@johnbender johnbender closed this Oct 11, 2011

@thatstephen - Thanks for the suggestion. I just added a note here on the linking pages docs section, under "inking without Ajax":


@johnbender @toddparker

We still need to file a bug against Apple so they can fix the issue in Safari.


@jblas - are you volunteering? ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment