Duplicate pages created in DOM

[okoskimi]

Duplicate page detection is based on data-url attribute, but the URL is not normalized. So, if you have a page structure like:

.../page1.html

.../dir2/page2.html


And open up first page1, navigate from page1 to page 2 with hyperlink <a href="dir2/page2.html"> and then navigate from page2 to page1 with hyperlink <a href="../page1.html">, the page navigation logic will look in DOM for a page with data-url attribute "dir2/../page1.html", which it of course will not find and so a duplicate page will be loaded into DOM. Using data-url attribute in page div will not help since the value that is looked for will depend on the location of the page where the link is.

Tested with Chrome browser.

Suggested solution: Normalize URLs before using them. At the same time you would probably solve the current problem that you cannot use absolute URLs like "/foo/bar/page.html" because it will break the URL used in the injected <base> element. So, if your current URL is "http://www.example.com/foo/#dir2/page2.html", then navigation to "../page1.html" should result in URL "http://www.example.com/foo/#page1.html" (and NOT "http://www.example.com/foo/#dir2/../page1.html"), and similarly navigation to "/foo/dir3/page3.html" should result in URL "http://www.example.com/foo/#dir3/page3.html" (and NOT "http://www.example.com/foo/#/foo/dir3/page3.html").

[scottjehl]

This makes good sense. Thanks. We'll land it ASAP

[scottjehl]

In re-reading, I like your suggestion for knocking off ../ and duplicate directories, but in practice I think this is going to be very complicated. Unfortunately, we don't have the luxury of letting a server resolve our paths for us, and I do worry that comparing strings and negotiating which segments to add or remove will add a bit of bloat.

That said, I do really want to see this happen.

I think a good start would be to tackle the ../ parts, simply chopping a segment off the end of the current path for each one that precedes a new link. Root-relative urls may be trickier, especially when dealing with ones that take an alternate path than our current location.pathName. in those cases, we'll need to follow the # with a "/" and full-path, so I don't think it'd be a bad thing to always do that.

Anyway, we'd love help in picking away a this one if you're interested!

[scottjehl]

Marked as Critical - will focus on this post-a4.

[scottjehl]

parallel discussion going on in this closed ticket: https://github.com/jquery/jquery-mobile/issues#issue/735

[okoskimi]

I have now approval to work on this, so I'll make a fork and do some hacking next week.

[okoskimi]

The functionality is now done, but when I pulled upstream changes, something broke in unit tests - need to investigate and fix before the patch can be submitted. In the meantime, here's a short description of what the patch does:

• path.clean() has been extended to canonize the url given as argument
• Relative urls (e.g. "../dir/file.html") are canonized to #dir/file.html format
• Same for absolute urls (e.g. "/dir/file.html"), if above in directory hierarchy this will produce something like #../../../dir/file.html (keeping the hash always relative to current location.pathname)
• Hashed urls can be used to load a page as external, e.g. ../dir/#file.html is resolved to a full URL (beginning with protocol), which again causes it to be interpreted as external by the isExternal() logic. This seemed to be the most intuitive semantic for hashed urls.
• You can use #/ to refer to $.mobile.firstPage (and relative/absolute urls that point to the first page will work too)

[okoskimi]

Created pull request for the patch: #1456

[scottjehl]

Closing this one out, as the new path fixes should take care of this one by normalizing all urls to absolute. Please let us know if you continue to see the bug anywhere! Thanks :)

[siddikshaik]

Hi all,

This Issue Still occurs for me...

Let me tell the scenario here..

My Initial url will be like this (http://siddik-0296/MCHome.do?action=list). So, the intial page will be created with the above URL..

Later when i change the url and do some operations and then i invoke the same(above one) url with # appending to it then a another pagerole will create with same html..

Second URL (http://siddik-0296/MCHome.do?action=list#/MCHome.do?action=list)

Now the problem is when i try to access values using ID (Ex : $('#MYID') ) then i will get the first value..

As ID is unique even though the document has got two ID's but it gives me only one..

Please suggest me a Solution for this...

Thanks and Regards,
Siddik

[siddikshaik]

As a work around i am using $('[id=MYID]') instead $('#MYID')..

That solves for me but still i think its a issue to create a same dom on the same page

[aschroder]

This was affecting me too, if you're not doing anything specific with query parameters, it might be caused by sloppy trailing slashes (as was my case). Make sure when you link to a page you're consistent. The list of elements solution siddikshaik suggests works if you need to have multiple pages - you can check if the element is visible, if the operations on them are expensive.