Nice! This reproduces in 63.3216 on Windows (but please note that Chrome 53 is extremely outdated and using it is dangerous at this point).

I believe SanitizeTextForPaste[1] needs to account for stripping control characters like \02 from the front of the string.

[1] https://cs.chromium.org/chromium/src/components/omnibox/browser/omnibox_view.cc?l=39&rcl=dc1e966077221ded65b3c19fdc16411be12a3176

Looking closer, the fix probably needs to be in OmniboxView::StripJavascriptSchemas just above, as that function is used for equivalent threats, like dragging URLs.

Yeah, my network has been very sporatic so it's been a pain to update, but I recently finally got a less.. significantly out of date version. This issue also occurs in Firefox apparently, I'll be reporting it to them soon as well.

I'm looking around, where would the final sanitization function be? Why not just use that, as opposed to SanitizeTextForPaste, because it seems to do the same thing and more.

Alright, I THINK that the finalized URL is a result of https://cs.chromium.org/chromium/src/components/omnibox/browser/autocomplete_input.cc?l=151 -- and it uses TrimWhitespace (which curiously, the omnibox isn't using, so it might be worth having the omnibox use string_util's TrimWhitespace.)

However: It should be failing in the first place (https://cs.chromium.org/chromium/src/components/url_formatter/url_fixer.cc?l=369) -- it returns false if there's a control character in the string. So it seems the issue is happening somewhere else, possibly outside of the URL formatter component entirely.

Re #5-- Yes, performing the same cleanup between the two areas is important; the Omnibox code is quite complex.

Your bug reproduces in Firefox 57. Would you like to file a parallel security bug in their bug tracker?

Yeah, that'd be ideal, I was intending to report it there later when I got a little more free time today.

Ugh. This was actually reported in  Issue 631847 , which has been public since June.

Uh oh, dang. I didn't even find that -- but I havent' found a similar bug in Firefox's Bugzilla so it's probably still worth reporting there. However, that's kinda awry if it's been an issue that long. I guess the best way to resolve this for now is to skip any prefixed characters with an ascii value of less than 32 when evaluating if the javascript URI is still there. I don't see that it'd strip aggressively at all because there wouldn't be anything but control characters (which you wouldn't have to strip either) for the purposes of preventing of preventing the previously found issues with allowing javascript: pastables. 

Merging into  bug 631847  per comments #9 and #10.

I'm going to drop view restrictions since the duplicate bug has been open for a long time. If you object, please let me know.

Go ahead; might encourage a more proper patch (I was going to write one but realized I don't have the resources to test it) with the added information this report includes.

Thanks!