1184589 - window.location.hash exposes spaces as %20

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Martin Thomson [:mt:]]

This is a tricky problem, but it seems like something has changed since Ffx 39.

Go to https://phonebook.mozilla.org/#search/doug%20turner

The address bar shows this with a space.  window.location.hash includes the "%20".

A brief survey shows that the web is inconsistent here and phonebook probably needs to be updated to handle it:
 Chrome (43) uses a space
 Safari (8.0.7) uses %20

Comment 1

[Boris Zbarsky [:bzbarsky]]

Fwiw, beta has the old behavior, aurora has the new behavior.

Per spec, such as it is, at https://url.spec.whatwg.org/#fragment-state the behavior is ... well, it depends.  It basically preserves whatever was passed in, afaict.  So if you do:

  location.hash = "doug turner";

then location.hash will be "doug turner".  But if you do:

  location.hash = "doug%20turner";

then location.hash will be "doug%20turner".  So in the steps to reproduce from comment 0 you would get the string "doug%20turner" from location.hash, I think.  Again, for whatever that's worth given the lack of browser interop here.

Comment 2

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Possible web compat regression.

Comment 3

[Anne (:annevk)]

I think we changed this on purpose in bug 1093611 to align with the specification.

Comment 5

[Valentin Gosu [:valentin]]

Are we now looking for a different behaviour for this?
As I see it, prior to bug 1093611, we weren't compatible with either Chrome&IE or Safari.
In bug 1149913 we decided that not having spaces in a URL is most important, so we ended up siding with Safari.

If people encounter hard compat problems, they can go back to the old behaviour by setting the dom.url.getters_decode_hash pref to true.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Are we now looking for a different behaviour for this?

No, so far we were trying to figure out whether this change is a problem.

Given that our new behavior matches Safari, I would guess it's not.  Most sites work in Safari.  ;)

Comment 7

[Kohei Yoshino [:kohei]]

Site compat doc: https://developer.mozilla.org/en-US/Firefox/Releases/41/Site_Compatibility#URLUtils.hash_no_longer_decodes_fragment

Comment 8

[Kohei Yoshino [:kohei]]

I sent a pull request to fix the phonebook issue. https://github.com/mozilla/phonebook/pull/6

Comment 9

[Julien Wajsberg [:julienw]]

Note: phonebook issue is bug 1184623

Comment 10

[:glob ✱]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> Note: phonebook issue is bug 1184623

the phonebook has already been fixed (via bug 1141421).

Comment 11

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Resolving this as won't fix based on comment #5. Also untracking as this change of behavior in handling spaces as %20 was by design and can be changed with the workaround mentioned in comment #5.

Comment 13

[Kohei Yoshino [:kohei]]

The document is currently at https://www.fxsitecompat.com/en-US/docs/2015/urlutils-hash-no-longer-decodes-fragment/