When I create a new page on the fly, any link I create that links to it throws an error when clicked; however, I CAN programmatically move to that page.
Ex: (assuming page #main already exists and that's the page we're on now)
$("<div data-role='page' id='test'>testing...</div>").appendTo($("body"));
$.mobile.changePage($("#test")); // WORKS
$("<a href='#test'>go to test></a>").appendTo($("#main")); // clicking this link FAILS, tries to ajax
This is true if the link is created first, as well. It is also true if I navigate to a different data-role="page", come back, and then click the link (thinking the parser might re-fire on load). It is also also true if the link already exists on site load and then the extra div is added dynamically.
I'll keep looking into this to see if I can pinpoint the problem.
EDIT: More research:
After checking the source, it appears that the "to" argument being passed to the $.mobile.changePage method is somehow not returning true to the "toIsObject" test, whereas other pages that were not dynamically created are. I don't know what $.type() does; if I try to use it outside the scope of execution I'm told it doesn't exist, and I did some searching in the source but haven't tracked it down yet. I'm assuming it does some kind of lookup within jQuery (widgets, perhaps?) because the type of the to argument is always a string. Anyway, there's some extra insight. I'll plug away again tomorrow but this is a big impediment for my current project...
We'll have to take a look at this. Keep posting details if you have 'em...
I think the gist of this bug is that when folks dynamically inject a page, they aren't tagging it with a @data-url attribute, so we aren't finding it. I suppose I can add some fallback code that checks to see if the page being requested is an embedded page, and if its not found via the data-url lookup, we could always do a 2nd pass lookup by id. What do you think?
We're already doing a fallback 2nd pass for catching references to the first embedded page of the application document since that might not have an id, and therefore no data-url value, associated with it.
I think if this isn't too much effort, that sounds like a great idea.
Fix landed on the HEAD: