Remove %3A escaping from blob: URLs
Contact emails
Spec
https://w3c.github.io/FileAPI/#DefinitionOfScheme
https://w3c.github.io/FileAPI/#unicodeBlobURL
https://url.spec.whatwg.org/#origin
Summary
Historically, blob URLs returned by URL.createObjectURL() looked like this:
blob:http%3A//www.html5rocks.com/4d4ff040-6d61-4446-86d3-13ca07ec9ab9
The %3A is an artifact of escaping the origin during serialization. I intend to remove this escaping (link to CL) to make blob URLs look like this:
blob:http://www.html5rocks.com/4d4ff040-6d61-4446-86d3-13ca07ec9ab9
Motivation
The %3A escaping is unnecessary and matches neither the spec nor other browsers.
Importantly, this change will make blink-generated URLs compatible with GURL’s origin parser (url/origin.h), which was written to follow the spec. Consistency here will allow the origin to be properly extracted from URLs at the content/ layer and above; such operations are currently broken.
This change will make Chrome match the behavior of Firefox and Safari. In IE11, blob URLs do not include origins, so its behavior is not applicable.
Interoperability and Compatibility Risk
Because blob URLs aren't valid across browsing sessions, this change is low risk. But it is nonetheless web-visible, and could affect pages that, for unimaginable reasons, try to manually parse the values of blob URLs.
As an encouraging reference point, it seems that Firefox has successfully changed the encoding of blob URLs in the last two years (per the comment in this discussion thread: https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0369.html).
Ongoing technical constraints
None. It's a single CL.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=603278
Link to entry on the feature dashboard
This change is hopefully too small to merit this. Please advise if not.
Requesting approval to ship?
Yes, in M52LGTM3 - I agree with the expectation that compat risk should be very low. But since we have no hard data, please ping this thread if one or two real world sites are discovered to be broken by this change somehow.