Potential Bug with URL Hash being decoded (Tested on Angular 1.4.2 & 1.4.7) #13245
Description
After browsing the code and reading http://tools.ietf.org/html/rfc3986#section-2.4 I'm still not sure if this is intended behavior. This is happening for us in one specific instance where we have Angular being used by a component on our page. A 3rd party script sets window.location.hash, and Angular's $locationWatch picks up the url and the url is decoded... When the 3rd party js script grabs the window.location.hash value, its now decoded and the third party script expects it to be encoded still which creates a bug. The reason it occurs in this case is that the third party script is splitting on the "/" character, so 942520H PROCAT SE KOHLER CV680 W/52 SIDE DISCHARGE gets encoded to /s/TPI/942502G_PROCAT_26HP_KAW_W%2F%2F61_SIDE_DISCHARGE//1
Angular modifies it to /s/TPI/942502G_PROCAT_26HP_KAW_W//61_SIDE_DISCHARGE//1. Which is put into json to send over the wire... So the decoding in the hash breaks that process...
Here is an example setting the window.location.hash = "%27" notice that it gets decoded...
From what I could glean from the spec this shouldn't happen...
"The characters slash ("/") and question mark ("?") are allowed to
represent data within the fragment identifier. Beware that some
older, erroneous implementations may not handle this data correctly
when it is used as the base URI for relative references (Section
5.1)."
I did find this in the source... looks like I'm hitting the or of the else, seems to happen across all browsers ;)
} else {
// - reloadLocation is needed as browsers don't allow to read out
// the new location.href if a reload happened.
// - the replacement is a workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=407172
return reloadLocation || location.href.replace(/%27/g,"'");
}