This is being discussed in the Pixelbook Help Forum, but it impacts all ChromeOS devices
https://productforums.google.com/forum/#!topic/pixelbook/XTjXmzT6e2w

#CBC-RS/TC-watchlist

 Issue 772601  has been merged into this issue.

 Issue 772473  has been merged into this issue.

 Issue 686649  has been merged into this issue.

Files app daily triage: I can confirm I can reproduce this issue.

1. I created a new image on my local Download folder (downloaded something from web).
2. I renamed the image (Ctrl+Enter) and removed the extension (.jpg).

The image immediately lost the thumbnail (since I was on thumbnail view) and opens on the default app (Google Keep).

If image inside Google Drive, it doesn't lose its thumbnail.

My Chrome version is 64.0.3282.190.

I also tried on my dev env Chrome version 67.0.3376.0, with same results.
-----------

Potential fix suggested on  crbug.com/772601 :
Utilize content sniffing implemented in https://codereview.chromium.org/224883008

Related bug/FR:  crbug.com/772601  - Quick view: show extension-less files properly

Priority 3 seems appropriate since there is a workaround available (to add the extension to the file).
-------------

This needs to be fixed on:
1. Thumbnail.
2. Open/Open with.
3. Quick View.
4. Gallery/Audio Player/Video Player.

The workaround is not great though - what if the user has no idea what the extension should be?

Exactly, and one of the concerns is that a file can be downloaded from the internet that could execute malicious code or run a script that could do some damage to your data, all based on the assumption that certain apps open bsed on the extension alone. It seems like the Google Drive file manager is a lot smarter than Files application.

This is not issue in individual applications, but due to the restriction of the filesystem and metadata provider.

Files from some external providers (like Google Drive) has MIME type attached by them, but doesn't exist in the local file system.
https://cs.chromium.org/chromium/src/ui/file_manager/file_manager/foreground/js/metadata/file_system_metadata_provider.js?q=contentMimeType&sq=package:chromium&l=1
https://cs.chromium.org/chromium/src/ui/file_manager/file_manager/foreground/js/metadata/external_metadata_provider.js?q=contentMimeType&sq=package:chromium&l=76

There's a logic to sniff the file type by reading first part of the file content, but seems it's not propagated (by|to) the metadata provider.
https://cs.chromium.org/chromium/src/extensions/browser/api/file_handlers/mime_util.cc?type=cs&sq=package:chromium&l=126

Files app doesn't currently support unknown file types; this is a known area we can improve.

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

Looks like there are some dupes/similar bugs - i'll let you collapse them as appropriate.