There is a patch on https://codereview.chromium.org/2397873002

This ran into a problem with the policy blacklist which uses the URL fixer to parse URLs like "file://*" which the URL fixer now rejects as invalid.

This type of string should not be passed through URLs. This will require some research to figure out what exactly is required for these.

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

commit 8b1643a13acc2663941caf671282f23305d00775
Author: brettw <brettw@chromium.org>
Date: Mon Oct 17 22:08:05 2016

Remove space from omnibox test.

The original bug for this test (603839) mentions a space in the host name. But
removing the space from this test and reverting the patch still makes the test
fail, so it seems the test itself is not dependent on the presence of the
space.

This is part of a patch to make some invalid characters like space and "*"
invalid in URLs. Since this test seems not dependent on the presence of the
space, I'm changing it in a separate pass.

BUG=652808

Review-Url: https://codereview.chromium.org/2423253002
Cr-Commit-Position: refs/heads/master@{#425787}

[modify] https://crrev.com/8b1643a13acc2663941caf671282f23305d00775/components/omnibox/browser/omnibox_edit_unittest.cc

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

commit 455784dee3dea2a618d4e4d1e6c1003ed55cd6b6
Author: brettw <brettw@chromium.org>
Date: Thu Oct 20 18:15:44 2016

Check for blacklist wildcards before creating GURL

The policy blacklist parser used to first check for "file" schemes first as a
special case before checking for wildcard hosts like "http://*", and the file
special-case had it's own wildcard special casing.

I am working on making "*" an invalid host character, and with this future
patch, creating a GURL of "file://*" will fail. This change moves the wildcard
handling above the file scheme checking so it will work regardless of whether
"*" is a valid host character or not.

The particular structure of this code looks like a result of adding the
wildcard handling ( https://codereview.chromium.org/1692503002/ ) after the
file handling was already in place.

BUG=652808

Review-Url: https://chromiumcodereview.appspot.com/2426733002
Cr-Commit-Position: refs/heads/master@{#426532}

[modify] https://crrev.com/455784dee3dea2a618d4e4d1e6c1003ed55cd6b6/components/policy/core/browser/url_blacklist_manager.cc

This is on hold because other browsers (at least Firefox and Edge) can make URL objects with garbage names like:
  new URL(“http://@#$@#$@#$/”);
They do not seem to do any (or at least much) validity checking at this level. Chrome canonicalizes these which leads to exceptions in some cases, and different strings in others. Restricting the characters in the way proposed will make this happen a lot more for some common cases like “http://*” (which Chrome’s settings itself uses).

It sounds like Firefox and Edge do not throw exceptions for garbage host names? Do they canonicalize to a different string?

The JS URL object seems to do no modifications. I think their JS URL object is different than what they use for network stuff, while Chrome's is the same.

It should be the same. Note that we have discussed adding more restrictions to host names, but Ryan (Google) was not on board: https://github.com/whatwg/url/issues/159. If you could give input there that'd be good.

Anne: What should happen when I do this?

  new URL(“http://@#$@#$@#$/”);

This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge