Obsolete
Status Update
No update yet.
Comments
ma...@gmail.com
Yes, in the end '%' in the iframes src url is encoded again: %3D -> %253D
This really breaks things, ugly when json is part of the query.
And yes, it is not an issue in any other browser I tested.
This really breaks things, ugly when json is part of the query.
And yes, it is not an issue in any other browser I tested.
ma...@qiwi.be
[Empty comment from Monorail migration]
cb...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Blink]
[Monorail components: Blink]
dt...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: -Blink Blink>Loader]
[Monorail components: -Blink Blink>Loader]
ja...@chromium.org
This sounds like a gurl bug? I don't see a label for that.
br...@chromium.org
Your URL has a hostname of "google.com ⁇"
which is then unicode-normalized to "google.com? ?" which is an invalid hostname so we escape the bad characters to make it "google.com %3F%3F"
This is how our canoicalization works. I suspect other browsers aren't canonicalizing the URLs as much. But I don't see the problem, since Chrome is telling you what it thinks the hostname is. I don't think Chrome's notion of the hostname is incorrect in this example, and I also don't see a problem (and I do see some benefit) to exposing a completely canonicalized URL in this case.
If you have a valid URL that this mangles, I would be interested in that.
which is then unicode-normalized to "
This is how our canoicalization works. I suspect other browsers aren't canonicalizing the URLs as much. But I don't see the problem, since Chrome is telling you what it thinks the hostname is. I don't think Chrome's notion of the hostname is incorrect in this example, and I also don't see a problem (and I do see some benefit) to exposing a completely canonicalized URL in this case.
If you have a valid URL that this mangles, I would be interested in that.
jh...@gmail.com
In my app, we noticed this because it seems to muck with '+' when used in a query string to escape a space.
myapp.com/frag/?q=Some+Value+With+Spaces
Somehow becomes:
myapp.com/frag/?q=Some%252BValue%252BWith%252BSpaces
So the plus gets encoded as %2B and then the percent gets encoded again as %252B. The parameter ends up getting decoded server-side with the '+' instead of the original spaces.
Somehow becomes:
So the plus gets encoded as %2B and then the percent gets encoded again as %252B. The parameter ends up getting decoded server-side with the '+' instead of the original spaces.
br...@chromium.org
br...@chromium.org
I should have added: So if you have a simple repro case, file a separate bug.
is...@google.com
This issue was migrated from crbug.com/chromium/273712?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Example URL:
data:text/html;charset=utf-8,<!DOCTYPE html><title>Test</title><script>var%20dummy%20=%20document.createElement('iframe');%20dummy.src%20=%20'http%3A//
Steps to reproduce the problem:
1. var dummy = document.createElement('iframe'); dummy.src = '
What is the expected behavior?
When setting the `src` of an `iframe` (or similar) element dynamically, Chrome (correctly) applies Unicode normalization. When you read out the `src` value afterwards, you get back a normalized version. That’s all good.
What went wrong?
However, it seems Chrome then filters out certain bad code points via URL-encoding (percent-escaping), but percent-escaping doesn't make sense anymore at that point. In fact, it breaks more than it helps. It might be better to match Firefox’s behavior and to just return the URL as-is.
Does it occur on multiple sites: N/A
Is it a problem with a plugin? N/A
Did this work before? N/A
Does this work in other browsers? Yes latest Firefox
Chrome version: 30.0.1592.0 Channel: n/a
OS Version: OS X 10.8.4
Flash Version: Shockwave Flash 11.8 r800