Skip to content

changePage breaks when data hash contains parentheses/apostropes #1383

Closed
konklone opened this Issue Apr 6, 2011 · 23 comments
@konklone
konklone commented Apr 6, 2011

The following causes a syntax error in alpha 4:

$.mobile.changePage({url: "index.html", data: {foo: "bar(baz)"}, type: "get"});

In Firefox 4, the error message in Firebug's console is:

"Syntax error, unrecognized expression: data-url='index.html?foo=bar(baz]')"

Attempts to change the page without the parentheses work fine, such as:

$.mobile.changePage({url: "index.html", data: {foo: "bar"}, type: "get"});
@mckamey
mckamey commented Apr 19, 2011

Note: Apostrope/Single-Quote also break changePage.

Issues #1383, #1408, #1468 are related.

Issue #1468 describes a workaround.

@drifting

On my implementation it's only the closing parenthesis that is causes an error. I have a search from that will pass results to a search page. Queries for "Some search (more" work whereas queries for "Some search (more)" break pageChange.

@drifting

I was able to get my forms working by running replacements on the serialized data bound to form submit event using the suggestion here: #1468

My new data looks like:
var newData = $this.serialize().replace('\'','%27').replace('(','%28').replace(')','%29');

I updated the data in the function: $( "form" ).live('submit', function( event ) {});

Hope that helps people having a similar problem.

@johnbender johnbender was assigned Aug 8, 2011
@michaelhull michaelhull added a commit to michaelhull/jquery-mobile that referenced this issue Sep 3, 2011
@michaelhull michaelhull Fix for issue #1383 - Avoids infinite loop when dataUrl contains ) or…
… '. I suggest switching to a hashtable like issue #1727 suggests for a permanent solution.
0ecd1c7
@johnbender

#2384

Additional discussion in that pull request on possible solutions (eg escaping the url).

@toddparker

@johnbender - Is this still an open issue?

@johnbender

@mrlyons

The pr didn't get merged for the reason cited in the pull request: we need to address this in a couple places by escaping the hashes.

@smjgithub

I'm currently using jquery.mobile-1.1.0 and I am serving it locally so that I could apply the partial fix from #1383.

Is this fix or a more complete version of the fix likely to make it into any official patch so that I can go back to serving jquery.mobile remotely?

@jaspermdegroot
jQuery Foundation member

Updated the topic of this ticket so it also mentions "apostropes".

@SixtoSaez

Ran across this issue in a pretty common usage scenario that may justify raising the priority of this issue. Our app passes names and such in the query string of the href attribute of a tags (see sample page: http://pastebin.com/TKybiryG). The name values (i.e. o'reilly) can sometimes contain single quotes which are a valid query string characters. Typical URL encode functions do not escape this character to a % encoding.

@dpolivy
dpolivy commented May 29, 2014

This still seems to exist in 1.4.2, and I'm hitting it with apostrophes in my query string portion of the url. Is there any progress on incorporating @SixtoSaez's PR or providing another fix?

@dpolivy
dpolivy commented Jun 4, 2014

Borrowing the "fix" from #1468, I've come up with a patch that appears to work (apply it here):

        _createDataUrl: function( absoluteUrl ) {
            return $.mobile.path.convertUrlToDataUrl( absoluteUrl ).replace('\'','%27').replace('(','%28').replace(')','%29');
        },

I haven't run the jQM test suite, and am not so familiar with how the data-url attribute is used, so it'd be great if one of the jQM team members could take a look. I'm happy to submit a PR for this if that would be easier/faster for getting a fix incorporated.

@johnbender / @uGoMobi can you take a quick look?

@jaspermdegroot jaspermdegroot added this to the 1.5.0 milestone Jun 5, 2014
@gabrielschulhof

The problem is a lot simpler than when you have a query string. Even if the external page you're attempting to reach has special characters, such as ' the selector will fail. The problem is we're assuming a URL can be stored in a DOM attribute and a query can be constructed for that DOM attribute by simple string concatenation. This is wrong.

@jaspermdegroot jaspermdegroot modified the milestone: 1.4.3, 1.5.0 Jun 5, 2014
@gabrielschulhof gabrielschulhof modified the milestone: 1.4.4, 1.4.3 Jun 5, 2014
@gabrielschulhof

@dpolivy can you please try http://view.jquerymobile.com/1383-escape-urls-in-data-url-selector/dist/jquery.mobile.js? Things should no longer be uri-encoded, even upon form submit.

@gabrielschulhof

@konklone @mckamey @drifting could you also please check out the link I gave @dpolivy above and tell me whether this addresses your problems?

@konklone
konklone commented Jun 7, 2014

...it's been 3 years since I reported this. I've moved on with my life.

@dpolivy
dpolivy commented Aug 20, 2014

@gabrielschulhof I think there may still be an issue lurking in the code here. When I have a URL that has a valid % in it, and provide that as a data-url in my markup, I get an Uncaught URIError: URI malformed from the last line of $.mobile.path.path.convertUrlToDataUrl.

As per our earlier discussions, and the "correct" behavior, the data-url specified in markup is NOT url encoded -- just HTML entity encoded where necessary. It looks like the code in _loadSuccess is extracting the data-url from the markup -- should it be url encoded at that time for consistency?

https://github.com/jquery/jquery-mobile/blob/master/js/widgets/pagecontainer.js#L526

@gabrielschulhof

@dpolivy can you please describe a specific scenario where you have a "valid %" as part of your initial markup? I've tried the setup below, but that does not result in any JS exceptions.

rootDirectory
    +----- weird-file-name.html
    +----- 100%test/
        +----- index.html

weird-file-name.html:

...
<a href="100%25test/index.html">100%test/index.html</a>
...

When I open weird-file-name.html in the browser and I click the link about, the file 100%tests/index.html is loaded without any problems.

@gabrielschulhof

It seems that the anchor's href needs to be URL encoded.

@gabrielschulhof

OK. I see. If I repeat the above scenario with the data-url inside 100%test/index.html specified a priori then I get the exception.

@dpolivy
dpolivy commented Aug 22, 2014

@gabrielschulhof Exactly; if you specify the data-url on the page, which we determined should NOT be url encoded, then you'll get the exception. I put in a simple fix to call encodeURI on the value returned from text() here, and it seems to fix it. I think it's safe since the proper behavior is for that value to be unencoded?

@gabrielschulhof

Well, that's easy enough to fix if I url-encode data-url upon retrieving it from the HTML coming in via Ajax. However, I've discovered a problem with this fix: It causes an unencoded URL to end up in the location when you click on a link to a page behind a URL with a percent sign in it. So, I need to review the whole fix to find the spot where I've introduced that mistake, because on master the correct, url-encoded URL ends up in the location - as it should be.

@gabrielschulhof

@dpolivy Exactly. That's how I fixed it, but, like I said, I found another problem with my fix. A regression I must avoid and against which I need to test before this can land.

@gabrielschulhof gabrielschulhof added a commit that closed this issue Sep 4, 2014
@gabrielschulhof gabrielschulhof Navigation: 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

Closes gh-7474
Fixes gh-1383
e412102
@gabrielschulhof gabrielschulhof added a commit that referenced this issue Sep 4, 2014
@gabrielschulhof gabrielschulhof Navigation: 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

(cherry picked from commit e412102)

Closes gh-7474
Fixes gh-1383
d3a412e
@agcolom agcolom added a commit to agcolom/jquery-mobile that referenced this issue Nov 26, 2014
@gabrielschulhof gabrielschulhof Navigation: 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

Closes gh-7474
Fixes gh-1383
cd59fe1
@gabrielschulhof gabrielschulhof added a commit to jquery/api.jquerymobile.com that referenced this issue Dec 30, 2014
@gabrielschulhof gabrielschulhof Page: Document that data-attribute data-url stores a non-URI-encoded …
…value

Closes gh-313
Re jquery/jquery-mobile#1383

(cherry picked from commit d5881e2)
582f8c8
@dpolivy
dpolivy commented Mar 17, 2015

@gabrielschulhof What's the correct way to handle ampersand/equals within query parameters in URLs? I've got all of these changes in my build of jQM, but in situations where I have an ampersand within a query string value, the data-url contains just the HTML encoded entity, e.g. data-url="/my/path?q=red+&amp;+blue". Thus, when the URL is updated (via replaceState), it ends up being unencoded, so if you refresh the page, the query string is broken because the & is parsed as another parameter.

Is there a proper way to handle this case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.