3

Firefox (but not Chrome) messes-up the location.hash result:

https://jsfiddle.net/nsoaee4q/14/

What workaround works for all valid fragment values?

Not this, note:

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<script>
"use strict";
location.hash = "'%97";

console.log(location.hash);
// Expected: #'%97
// SUCCESS on Chrome
// FAIL on Firefox: #%27%97

// Attempted fix
console.log('#'+decodeURIComponent(location.href.split("#")[1] || ""));
// FAIL 'Uncaught URIError: URI malformed'
</script>

Note: This is not a duplicate of Encoding of window.location.hash and that question's accepted answer's solution is faulty.

UPDATE: The above example's %97 is claimed in comments to be invalid. Here's an example that avoids that issue:

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<script>
"use strict";
location.hash = "%20'";

console.log(location.hash);
// Expected: #%20'
// SUCCESS on Chrome
// FAIL on Firefox: #%20%27

// Attempted fix
console.log('#'+decodeURIComponent(location.href.split("#")[1] || ""));
// FAIL: # '
</script>

Note: Title was previously: "How can I workaround Firefox's bugged location.hash read?", changed for clarification.

Note: Kaiido's answer below of 2017-01-10 doesn't meet the requirement to work for all valid hash values, but does meet a less strict requirement, as explained in its comments.

Note: This bug report is related https://bugzilla.mozilla.org/show_bug.cgi?id=1329960 , pic https://i.stack.imgur.com/uvLLX.png

Community
  • 1
  • 1
ChrisJJ
  • 2,191
  • 1
  • 25
  • 38
  • try `unescape` insead of `decodeURIComponent` – Jaromanda X Jan 10 '17 at 01:15
  • the actual error in decodeURIComponent is because `%97` is an invalid URI sequence – Jaromanda X Jan 10 '17 at 01:19
  • 1
    @JaromandaX unescape is deprecated. – epascarello Jan 10 '17 at 01:22
  • indeed it is - but the text fragment isn't a valid URI sequence, so - rock ... hard place – Jaromanda X Jan 10 '17 at 01:23
  • 3
    Solution: use a valid `location.hash`. – StackSlave Jan 10 '17 at 01:25
  • SHouldn't the 97 be `%E2%80%94` for n-dash or do you actually want percent sign followed by 97? – epascarello Jan 10 '17 at 01:32
  • The problem with any solution like this is that it will do the wrong thing on non-Firefox browsers, unless you add a check for the browser type. – Barmar Jan 10 '17 at 01:56
  • @ epascarello, I actually want what it says. – ChrisJJ Jan 10 '17 at 12:14
  • @Barmar "The problem with any solution like this is that it will do the wrong thing on non-Firefox browsers" I'm hoping for a browser-unspecific solution as per http://stackoverflow.com/questions/1703552/encoding-of-window-location-hash (but working). – ChrisJJ Jan 10 '17 at 12:15
  • @PHPglue, the example value is a valid location.hash value. See http://stackoverflow.com/questions/26088849/url-fragment-allowed-characters – ChrisJJ Jan 10 '17 at 12:19
  • @ChrisJJ `%` is not in this list. It talks about *percent-encoded characters*, which do start by a `%` character, but `%97` is none of these encoded characters and `%` alone isn't either, and needs to be encoded as `%25` – Kaiido Jan 10 '17 at 12:35
  • @ChrisJJ When dealing with bugs, browser-unspecific solutions can be difficult to find. It reminds me of the questions that ask how to process improperly-created JSON that has unescaped quotes in it -- there's no completely reliable solution because the whole point of escaping is to prevent exactly that ambiguity. – Barmar Jan 10 '17 at 15:56
  • 1
    "It talks about percent-encoded characters ... but %97 is none of these encoded characters" It includes %97 under 'percent-encoded characters (a % followed by two hexadecimal digits)'. %97 is a valid percent-encoded character. Specifically it is a percent-encoded unreserved character. The fact it is unreserved does not make it invalid encoded. – ChrisJJ Jan 10 '17 at 22:31
  • @Barmar "It reminds me of the questions that ask how to process improperly-created JSON that has unescaped quotes in it" It shouldn't. This case's example is not improperly created. – ChrisJJ Jan 10 '17 at 22:32
  • @ChrisJJ What's similar is that you're trying to decode something that's ambiguous because something was done wrong to create the data. In this case, it was done wrong in the browser implementation. – Barmar Jan 10 '17 at 22:44
  • When you get the value `#%27%97`, there's no way to know if it's because the code originally did `location.hash = '%27%97';` in a Chrome or it did `location.hash = "'%97";` in Firefox. – Barmar Jan 10 '17 at 22:47
  • @Barmar. On that we agree. I wasn't endorsing decodeURIComponent. I included it only to show that this solution proposed by another was inadequate. In location.href, I see no way of resolving the ambiguity. – ChrisJJ Jan 11 '17 at 00:10

0 Answers0