changePage breaks when data hash contains parentheses/apostropes

[konklone]

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]

Note: Apostrope/Single-Quote also break changePage.

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

Issue #1468 describes a workaround.

[driftingly]

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.

[driftingly]

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]

#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]

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]

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]

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?

[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.

[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]

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

[dpolivy]

@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]

@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.

[dpolivy]

@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+&+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?