changelog.md

• Correctly (un)escape data-url all throughout the code Also removes code dealing with nested list URL tokens (subPageUrlKey) The initial bug was regarding the need to use selector-escaping when looking for pages inside the DOM via their data-url attribute, because the the data-url may contain "weird" characters like parantheses, single, and double quotes. During the process of fixing this it became clear that the data-url attribute can sometimes end up having a URL-encoded value - but not always. This makes proper string comparison, much less selector-escaping, impossible. So, it became necessary to require that data-url never be url-encoded. Conversely, the URL that ends up in the location when using replaceState() must be URL-encoded, otherwise, upon deep linking, one may end up with an invalid URL. For example, if the URL contains an actual percent sign, and the URL is placed in the location via replaceState(), the percent sign must be URL-encoded in order for deep-linking to work. Below are the original commit messages that have been squashed: Pagecontainer: Escape dataUrl when trying to find page based on it Navigation: Make sure location is encoded when going to a funky page Pagecontainer: Test that _find() throws not when looking for weird URLs Init: Correctly assign data-url for initial page Init: Make sure "data-url" attribute for initial page is decoded Pagecontainer: Decode URI when assigning to "data-url" during _parse() Pagecontainer: Use decoded URL to build selector for data-url Pagecontainer: Call convertUrlToDataUrl() via _createDataUrl() Path: Always uri-decode when computing dataUrl Pagecontainer: Remove extra decoding step, now part of _createDataUrl() This also removes the possibility that a URL gets double-decoded. Pagecontainer: Test behavior of _find() in the face of weird URLs Navigation: Use data-url retrieved from Ajax request in its encoded form Pagecontainer: Pass encoded URL to $.mobile.navigate() Init: Rename JS file with spaces in it (#1383, d3a412e)
• When going forward, grab transition from current entry Our history entries contain exactly one transition: The one used to arrive at the entry. In addition, the index of the current entry and that of the previous entry is updated before the value for the transition is computed. So, it makes sense, when going backwards, to read the transition value from the previous entry, because that value stores the transition that was used to get there from where history is currently at. However, when going forward, it makes no sense to read the transition value from the previous entry, because that one stores the transition that was used to reach it, not the transition that must be used to reach the next entry. (#1867, #4951, 8ea937f)
• initialDst no longer needed for resolving funky initial URLs (#7177, 0095c40)