I see this on desktop as well, so we're presumably getting this behavior from the omnibox code.

@mpearson @pkasting does it seem reasonable to disable file navigations on OSes that don't have a user-visible filesystem? I don't think file:// urls will ever work on iOS.

> does it seem reasonable to disable file navigations on OSes that don't have a
> user-visible filesystem? I don't think file:// urls will ever work on iOS.

Yes.

Peter will know better whether the best idea is to force these types of inputs on these platforms to be queries (and hence we never would add what-you-typed URL match) or to revise HistoryURLProvider::SuggestExactInput() to just return an invalid URL if the destination URL not normally navigable on the platform in use.

One question is what should happen if the user actually enters "file:///something".  I suspect we should try to navigate, and fail, instead of forcing this to be a search on these platforms.  The answer to this question determines whether a change to the parsing code is needed.

Note that on Windows, /n does not navigate by default.  I think this is a POSIXism in the fixup code.  One possibility here is that we should #if that POSIXism to not be true on iOS.

We may also need to make a change to "not suggest a URL WYT match" in any file: case on iOS.

These three changes overlap but are all at least partly distinct.

 Issue 322042  has been merged into this issue.

Of the various parts in comment #4, I think the easiest and most accurate is to not suggest a file:// URL-what-you-type match on a platform that doesn't support them (iOS, maybe others) unless the input explicitly includes the scheme.  I believe this means the change can be scoped to history_url_provider.cc.