Closed
Bug 1184589
Opened 9 years ago
Closed 9 years ago
window.location.hash exposes spaces as %20
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox40 | --- | unaffected |
firefox41 | --- | wontfix |
firefox42 | --- | wontfix |
People
(Reporter: mt, Unassigned)
References
Details
(Keywords: regression, site-compat)
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•9 years ago
|
||
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•9 years ago
|
||
[Tracking Requested - why for this release]: Possible web compat regression.
status-firefox40:
--- → unaffected
status-firefox41:
--- → affected
tracking-firefox41:
--- → ?
tracking-firefox42:
--- → ?
Keywords: regressionwindow-wanted
Comment 3•9 years ago
|
||
I think we changed this on purpose in bug 1093611 to align with the specification.
Updated•9 years ago
|
Keywords: site-compat
![]() |
||
Updated•9 years ago
|
Keywords: regressionwindow-wanted
Comment 5•9 years ago
|
||
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•9 years ago
|
||
> 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•9 years ago
|
||
Site compat doc: https://developer.mozilla.org/en-US/Firefox/Releases/41/Site_Compatibility#URLUtils.hash_no_longer_decodes_fragment
Comment 8•9 years ago
|
||
I sent a pull request to fix the phonebook issue. https://github.com/mozilla/phonebook/pull/6
Comment 9•9 years ago
|
||
Note: phonebook issue is bug 1184623
Comment 10•9 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #9) > Note: phonebook issue is bug 1184623 the phonebook has already been fixed (via bug 1141421).
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.
Status: NEW → RESOLVED
Closed: 9 years ago
tracking-firefox41:
? → ---
tracking-firefox42:
? → ---
Resolution: --- → WONTFIX
Comment 13•9 years ago
|
||
The document is currently at https://www.fxsitecompat.com/en-US/docs/2015/urlutils-hash-no-longer-decodes-fragment/
You need to log in
before you can comment on or make changes to this bug.
Description
•