Bisected to fcbb1bd7fd6a78847d95a422f10ca5908c02f521 = https://crrev.com/c/853036 by mmenke@chromium.org
"Don't sniff file URLs for HTML."
Landed in 66.0.3337.0

The new behavior is intended, see  issue 777737  for details.

Thank you for the link!

Reading through that linked discussion, it seemed like this was not exactly considered a big deal, but that no one could think of any use cases for keeping the behaviour, (apart from WebView,) and hence it was changed.

In my case, I have been automating the downloading of hundreds of webpages, while trying to preserve the directory structure and naming conventions. These files are then used when their information is needed to be referenced but no internet connection is available. The downloads are copied onto the storage for any device, and then the users can open their browser of choice to browse the info, without requiring a webserver or any technical knowledge. 

Due to the clean/friendly URL paradigm most websites do not display file extensions in the URL, and so the downloaded pages similarly have no file extension. 

Two solutions spring to mind, algorithmically adjust all the downloaded file extensions and links therein (seems needlessly complex,) or advise users to avoid Chrome or use a specific older version of it (not ideal.)

So yeah, if this is the kind of thing where user feedback is welcomed, then this is just my vote for reinstating the behaviour of interpreting html in a file with no extension, in cases where the content clearly identifies it as html (eg. from a doctype tag on the first line.) To me this would be the expected behaviour. Due to the locked-down nature of offline/no-server browsing and the difficulty of getting someone to run a file this way, I believe the utility of allowing it far outweighs the negligible possibility of it being used as an weak attack vector. Would like to see Chrome give a little more love to people who make use of it offline without a server. 

mikeinside@ Thanks for the issue.

Tested this issue on Windows 10 on the reported version 66.0.3359.139 and the latest Canary 68.0.3414.0 by following the below steps.

1. Saved a html code to a notepad without any extension.
2. Loaded the file on chrome and it is displayed as a raw source.
3. Renamed the file with .html extension and loaded the file. 
4. Can observe the file is rendered the same as before and the file name is displayed as .html.txt in the omnibox on Chrome.
Attached is the screen cast for reference.

The same behavior is observed on good Build 66.0.3335.0 as per comment #1.

Please check and confirm if anything is missed from our end in triaging the issue.

Thanks..

Deleted: 837920.mp4 2.1 MB

	837920.mp4 2.1 MB View Download

Hi Susan,

Thanks for looking into this and adding a screencast to make it easy to follow along. I believe even though you changed the save type to "All Files" in notepad, it still gave the file a .txt extension. 

If you click on the "View" tab at the top of the Windows Explorer window, then put a check in the "File Name Extensions" box in the "Show/Hide" panel, then you will see the true filename which is "asdf.html.txt" as correctly reported by Chrome. 

Once the true extension is visible in explorer, if you then change it to asdf.html I believe you will see Chrome correctly display it, whereas if you change it to asdf with no extension it will not. 

It is only in that final case of interpreting a file with no extension where I am hoping Chrome's behaviour can be changed back to how it previously operated; i.e. that in a file with no extension it can automatically determine whether the contents are html (by looking for doctype for example,) and if so then rendering it as normal.

As mentioned in comment 1, this appears to be working as intended:

https://bugs.chromium.org/p/chromium/issues/detail?id=777737