Able to reproduce this issue on reported version 63.0.3239.84 and on latest canary 65.0.3309.0 using Windows 10, Mac 10.13.1, Ubuntu 14.04, this issue is seen from M50[50.0.2661.0]. Hence considering this issue as Non-Regression and marking as Untriaged.

Thanks!

The Omnibox is suggesting both ftp:// and http:// and, in fact, http has a higher score, but only ftp is marked 'can be default'.

At least defaulting to ftp:// for ftp.[TLD+1] is intentional (and matched Firefox when we did it, though Firefox no longer does this), but when there is no subdomain here, this is probably a mistake.

It's possible we should match Edge/Firefox current behavior and remove the default "ftp://" scheme on ftp. subdomain entries, which would fix this as a side effect; but that's likely to make some people complain.

FTP should be considered deprecated (Though we're unlikely to remove support for quite a while, just because we'd want a viable extension to continue to provide support for those few who still need it), so I think we'd be fine removing ftp-related magic for omnibox autocomplete.  I say that as one of the FTP maintainers.

I have a CL that makes the proposed change: https://crrev.com/c/875201.

But the URL fixup code is used all over the place: https://cs.chromium.org/search/?q=url_fixer.h.

My CL doesn't break any tests (other than the fixup test that simply verifies the code I changed) but I worry that there's some obscure feature that expects this ftp:// behavior.

Would it make sense to try to invite more feedback on this? Or mmenke, are you comfortable at an FTP maintainer saying that anything that depends on this *should* change?

Skimming over consumers, ArcIntentHelperBridge is the one that makes me most nervous, though I certainly could be missing others, followed by the SafeBrowsing one.  It's unclear what the expectations of consumers of this API are.  I'm fine with trying to get more feedback from consumers (Particularly those two), but I do think behavior here should change, if we can reasonably do so.

FWIW, I'm fine with Just Changing This.

I think this CL is safe for ArcIntentHelperBridge since we don't even expect something with the ftp scheme to be sent to us [1]. I Am not an OWNER for this part so I would ask hidehiko@ or yusukes@ first :)

[1] = https://cs.chromium.org/chromium/src/components/arc/intent_helper/arc_intent_helper_bridge.cc?sq=package:chromium&dr=CSs&l=64

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

commit e86e71037d21854403f325cd30e986ffde87ea49
Author: Justin Donnelly <jdonnelly@chromium.org>
Date: Thu Jan 25 18:40:23 2018

Remove default ftp scheme on omnibox inputs starting with "ftp.".

Support for ftp is deprecated so encouraging its use with a
special-case fixup no longer makes sense.

Bug:  798166 
Change-Id: I8644164cf7229b435c1c452c74a33f26fb4543bb
Reviewed-on: https://chromium-review.googlesource.com/875201
Commit-Queue: Justin Donnelly <jdonnelly@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531959}
[modify] https://crrev.com/e86e71037d21854403f325cd30e986ffde87ea49/components/url_formatter/url_fixer.cc
[modify] https://crrev.com/e86e71037d21854403f325cd30e986ffde87ea49/components/url_formatter/url_fixer_unittest.cc