New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't link to dynamically created data-role="page" #1243

Closed
akisma opened this Issue Mar 15, 2011 · 4 comments

Comments

Projects
None yet
3 participants
@akisma

akisma commented Mar 15, 2011

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

$.mobile.changePage($("#main")); 
$("<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...

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Mar 17, 2011

Contributor

We'll have to take a look at this. Keep posting details if you have 'em...

Contributor

toddparker commented Mar 17, 2011

We'll have to take a look at this. Keep posting details if you have 'em...

@ghost ghost assigned jblas May 17, 2011

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 21, 2011

Contributor

@toddparker @scottjehl

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.

Contributor

jblas commented Sep 21, 2011

@toddparker @scottjehl

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.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Sep 21, 2011

Contributor

I think if this isn't too much effort, that sounds like a great idea.

Contributor

toddparker commented Sep 21, 2011

I think if this isn't too much effort, that sounds like a great idea.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 21, 2011

Contributor

Fix landed on the HEAD:

80b0e99

Contributor

jblas commented Sep 21, 2011

Fix landed on the HEAD:

80b0e99

@jblas jblas closed this Sep 21, 2011

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