Tabs: URLs encoded in anything other than UTF-8 will throw an error

Sorry, i did a bad copy/paste, here's the actual code by now :

function isLocal( anchor ) {
	return anchor.hash.length > 1 &&
		decodeURIComponent(anchor.href.replace( rhash, "" )) ===
			decodeURIComponent( location.href.replace( rhash, "" ) );
}

;)

Hi badatos,

Thanks for taking the time to contribute to the jQuery UI project. I'm not seeing the behavior that you're describing: http://jsfiddle.net/tj_vantoll/6sK7H/.

Could you alter my test case so that it shows the issue you're experiencing?

Thanks.

Hi tj.vantoll !

Thank you for your quick response.

In fact, the bug comes when the special char is in the page URL itself.

You can easily check the bug with this URL :

http://fiddle.jshell.net/6sK7H/show/?variable=alg%E8bre

i added a fake variable in your fiddle URL, and the 2 contents are melted now !

Just remove the %E8, and it works again :

http://fiddle.jshell.net/6sK7H/show/?variable=algebre

With my correction, it will works in both cases.

Well, your proposed fix is obviously not the correct fix as you're effectively removing the decoding. How did you get the %E8 in the first place? The proper encoding for è is %C3%A8.

Replying to [comment:4 scott.gonzalez]:

Well, your proposed fix is obviously not the correct fix as you're effectively removing the decoding. How did you get the %E8 in the first place? The proper encoding for è is %C3%A8.

The test was on a page using charset iso 8859-1, and %E8 is "è" in this case. "%C3%A8" is in UTF-8.

(n.b. :sadly, i can't change the page to UTF-8. )

How do you end up with the URL? Are you manually encoding it or is a browser encoding it?

Replying to [comment:6 scott.gonzalez]:

How do you end up with the URL? Are you manually encoding it or is a browser encoding it?

The page is called by a form like this :

<form action="http://localhost/search_engine.html#searchform" method="get">
  <input name="search_keywords" value="algèbre" >
</form>

Input is completed by user.

For my issue, i just can change method to "post", and the problem is quickly solved, but i thought it was better to warn you about this.

Thanks, that explains it. So here's the problem: The ISO-8859-1 page will generate a URL that is encoded using ISO-8859-1. However, decodeURIComponent() ALWAYS uses UTF-8 for the character set. I honestly don't think this is something we can properly fix. My only thought is that we can wrap the decoding in a try/catch and just accept the fact that there are some situations we can't handle. Perhaps when Safari 5.1 dies out we can just remove the encoding, but we'll need to verify that #8896 is actually limited to spaces in other browsers.

I agree with you,

A try/catch will probably do the job fine.

Anyway, there obviously will be less and less pages in ISO-8859-1, I hope...

Thank's again for the really good job you all do with Jquery UI.

I have the same problem. I used the following workaround

http://stackoverflow.com/a/19696946/684229

So my patch to jqueryui looks like this:

function isLocal( anchor ) {
        return anchor.hash.length > 1 && 
                decodeURIComponent( unescape( unescape( anchor.href.replace( rhash, "" ) ) ) ) ===
                        decodeURIComponent( unescape( unescape( location.href.replace( rhash, "" ) ) ) );
}

Note that there should probably be repeat-until loop which would call unescape until the result is the same.

But please note that this workaround is not clean and normally only UTF-8 characters should be used in URLs. The clean solution to this problem (appart from changing the page encoding to UTF-8, which is not always possible) is discussed here

http://stackoverflow.com/q/19702662/684229

Please if you know the answer post it there.

Replying to [comment:10 telensky]:

decodeURIComponent( unescape( unescape( anchor.href.replace( rhash, "" ) ) ) ) === decodeURIComponent( unescape( unescape( location.href.replace( rhash, "" ) ) ) );

Multiple decoding seems very wrong. Regardless of whether it can result in correct behavior.

Note that there should probably be repeat-until loop which would call unescape until the result is the same.

No, we should just check raw and decoded.

But please note that this workaround is not clean and normally only UTF-8 characters should be used in URLs.

Actually, URLs can't be UTF-8 in all cases, which is what this ticket is all about.

@badatos I actually don't see any way to make this actually work. Is your goal just to avoid getting an error, not to actually support matching URLs?

Replying to [comment:12 scott.gonzalez]:

@badatos I actually don't see any way to make this actually work. Is your goal just to avoid getting an error, not to actually support matching URLs?

Me neither... I think it could be just fine if it don't throw an error anymore, just ignoring malformed urls...

Tabs: Don't decode URLs if they're not UTF-8. Fixes #9518 - Tabs: URLs encoded in anything other than UTF-8 will throw an error.

Changeset: 874865842bdbbf5ec48ee41640951e9f103c0f16