You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect the behavior described below is a desirable feature and not a bug, but I found it confusing until I figured it out.
In brief, the behavior is: If one passes a URL to hs.urlevent.openURL() and that URL contains any parameter values with reserved characters that need to be escaped, such as a space, it will escape all parameter values, including already escaped characters since it escapes the percent sign as part of the escaping process.
Here is my case an example of how this confused me. This is all in the context of building URLs to create GMail messages, but I think the issues is a general one.
Normally openURL() handles escaping of characters such as spaces in a URL for you, so the following will result in a subject (provided by the "su" parameter) of "Candy Chocolate":
Now say I want the subject to be "M&Ms" instead of "Candy Chocolate". Not surprisingly, a simple approach of putting the ampersand in the URL doesn't work since the URL will not be encoded and the "&Ms" will get passed to the browser which will treat it like another parameter. The following results in a subject of "M":
So all would seem to be well, until one adds a space to a parameter value in the URL. This causes all parameter values to be encoded, including the percent sign for the escaped ampersand. So the following results in a literal subject of "Candy M%26Ms" in the GMail message:
And note, the space doesn't have to be in the same parameter value. The following URL, with a space in a separate body parameter, will have the side effect of double encoding the subject and causing it to be "M%26M":
As I said, I don't know this behavior is wrong, but given how one parameter value can cause changes in other parameter values, it took me a while to sort out what was going on.
If there is a behavior change to be made, I would suggest openURL() should never encode parameter values as to not encourage one to rely on it to do so, since it seems fragile.
The text was updated successfully, but these errors were encountered:
I suspect the behavior described below is a desirable feature and not a bug, but I found it confusing until I figured it out.
In brief, the behavior is: If one passes a URL to hs.urlevent.openURL() and that URL contains any parameter values with reserved characters that need to be escaped, such as a space, it will escape all parameter values, including already escaped characters since it escapes the percent sign as part of the escaping process.
Here is my case an example of how this confused me. This is all in the context of building URLs to create GMail messages, but I think the issues is a general one.
Normally openURL() handles escaping of characters such as spaces in a URL for you, so the following will result in a subject (provided by the "su" parameter) of "Candy Chocolate":
Now say I want the subject to be "M&Ms" instead of "Candy Chocolate". Not surprisingly, a simple approach of putting the ampersand in the URL doesn't work since the URL will not be encoded and the "&Ms" will get passed to the browser which will treat it like another parameter. The following results in a subject of "M":
The obvious thing to do is encode the ampersand using "%26" as follows. This works and the following will result in the desired subject of "M&Ms":
So all would seem to be well, until one adds a space to a parameter value in the URL. This causes all parameter values to be encoded, including the percent sign for the escaped ampersand. So the following results in a literal subject of "Candy M%26Ms" in the GMail message:
And note, the space doesn't have to be in the same parameter value. The following URL, with a space in a separate body parameter, will have the side effect of double encoding the subject and causing it to be "M%26M":
As I said, I don't know this behavior is wrong, but given how one parameter value can cause changes in other parameter values, it took me a while to sort out what was going on.
If there is a behavior change to be made, I would suggest openURL() should never encode parameter values as to not encourage one to rely on it to do so, since it seems fragile.
The text was updated successfully, but these errors were encountered: