Skip to content
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.

Bug in pagecontaner.js (v1.4.x) #7177

Closed
srgstm opened this issue Feb 25, 2014 · 3 comments
Closed

Bug in pagecontaner.js (v1.4.x) #7177

srgstm opened this issue Feb 25, 2014 · 3 comments

Comments

@srgstm
Copy link

srgstm commented Feb 25, 2014

Pagecontaner widget has _handleDestination private method. The last 'if' statement in this method contains comparison:

history.stack[0].url !== history.initialDst.replace( $.mobile.dialogHashKey, "" )

However this comparison always evaluates to true because left part refers to full URL and the right part refers to just the hash part (with the # stripped out).

@gabrielschulhof
Copy link

OK, this is part of funky-initial-URL-handling ... I'll take a look ...

@gabrielschulhof
Copy link

Hmmm ... it seems that it is never evaluated in any of our tests, except in a unit test specifically designed to hit that method.

@gabrielschulhof
Copy link

In the process of removing initialDst from the code, which really is useless, I came across an interesting nav behaviour when deep-linking:

  1. Open http://jsfiddle.net/zm6kprsf/1/show/light/#/k9L6hpn8/1/show/light/ in your browser (this is a URL of the form http://domain/path1/#/path2, meaning that the page at path2 should be displayed in the end and the URL of path2 should show up in the location in the end)
  2. Click on "Page 2", which is a link to an internal page

At this point, the location will display /path1/#page2 instead of /path2/#page2. This is bad, because opening an internal page should only change the hash, not the path.

The sequence tests should've caught this but I forgot to include an assertion that checks the location :(

@arschmitz do you think this is bad enough to warrant a fix?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants