Bug 561644  has more background and motivation for this change.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1b17dc30c89fc6a7a70a490ac942e853537fc2b9

commit 1b17dc30c89fc6a7a70a490ac942e853537fc2b9
Author: nick <nick@chromium.org>
Date: Fri Apr 15 21:34:04 2016

Remove URLencode/URLdecode for the inner origin of blob: URLs

This changes the value of "blob:" URLs from looking like this:
   blob:http%3A//localhost%3A8000/e80e38b8-cfe6-4b35-94c1-8519df140ede
To this:
   blob:http://localhost:8000/e80e38b8-cfe6-4b35-94c1-8519df140ede

The former case appears to be how Chrome has always done things. However, it is not spec compliant, and blob URLs produced this way are not understood properly by GURL/url::Origin.

The new behavior makes Chrome consistent with Firefox, Safari, and https://w3c.github.io/FileAPI/#unicodeBlobURL

I believe this is safe change, because blob URLs have transient lifetimes, that never outlast a browsing session.

blink-dev "Intent to Implement/Ship" thread: https://groups.google.com/a/chromium.org/d/msg/blink-dev/zY4JH54zZhc/PJlsDr35BAAJ
BUG= 561644 , 603278 
TBR=brettw@chromium.org

Review URL: https://codereview.chromium.org/1878273002

Cr-Commit-Position: refs/heads/master@{#387703}

[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/chrome/android/javatests/src/org/chromium/chrome/browser/util/UrlUtilitiesTest.java
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/chrome/browser/ssl/ssl_browser_tests.cc
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/components/url_formatter/elide_url_unittest.cc
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/content/browser/fileapi/fileapi_message_filter.cc
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/content/browser/fileapi/fileapi_message_filter_unittest.cc
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/native_client_sdk/src/tests/nacl_io_test/http_fs_test.cc
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/LayoutTests/fast/files/apply-blob-url-to-xhr-expected.txt
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/LayoutTests/fast/files/workers/worker-apply-blob-url-to-xhr-expected.txt
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/xhr-to-blob-in-isolated-world.html
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/LayoutTests/inspector/elements/styles-4/styles-url-linkify-expected.txt
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/LayoutTests/inspector/elements/styles-4/styles-url-linkify.html
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/Source/platform/blob/BlobURL.cpp
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp
[modify] https://crrev.com/1b17dc30c89fc6a7a70a490ac942e853537fc2b9/third_party/WebKit/Source/platform/weborigin/SecurityPolicyTest.cpp

Work is completed & landed. Without contraindicating evidence, will ship in M52.

I believe this change will break code that sends blob URLs to HTML audio. See the attached file that hosts two audio objects. The first is fed the colon-encoded URL currently generated; the second is fed the URL with the encoding removed. The first plays but the second doesn't.

Deleted: test3.html 701 bytes

test3.html 701 bytes View Download

Hi arf@blossom.com: Thanks for the code snippet and for taking the time to comment on this bug.

I think if you test your example on the latest Chrome canary ( https://www.google.com/chrome/browser/canary.html ), you will find that window.URL.createObjectURL returns values without the %3A escapes, so the url.replace() operation doesn't do anything, and thus both the |audio1| and |audio2| elements are able to play the audio blob.