A file saved from the internet was save as shown, with a name of the form "*.com" . Caja is reporting that as an executable, but gvim shows the content in the image below, and it is clearly not an executable.
Since the practice of deciding the filetype based on filename-ending is generally accepted as a valid way, caja is perfectly right.
The file is missing a magic number/string so the fallback for filetype recognition is filename-suffix
It would be better, ofcourse, to use a magic number/string (used in UNIX/Linux) or a separate filesystem supported field like what is sometiomes called "filetype field", "second filename" or "filename extension" (which was in use in VMS and DOS but doesn't exist in UNIX, Linux or Windows)
To keep compatibility , all platforms that didn't support a second filename field added the second filename as a suffix to the first filename, separated by a dot.
Thanks to this, everyone is now wrongly calling this suffix a "filename extension" (which it is not!) and determining filetype based on this is since then perfectly acceptable.
Now onto the ".com" suffix:
Filenames ending in .com are, just like .exe, based on suffix, rightfully recognized a DOS/Windows executable. .com files were executable files, just like .exe files, but much simpler: for instance, they had no header and were not relocatable.
You could, however, file a bug against the creator of the HTML file which should not have a name ending in .com because that name suffix was already taken and registered since 1980.
EDIT: I was quite wrong in my assumption:.
caja does recognize html by signature but prioritizes filenamesuffix over magic number (see next post)
I tested this on my desktop with a HTML file where I changed the name to
'blablabla.com' and it still got recognized as a HTML file.
This is on Ubuntu-MATE 22.04 LTS (MATE 1.26.0 ) and on Ubuntu-MATE 24.04
If you are also on Ubuntu-MATE 22.04 LTS (MATE 1.26.0 ) or newer, updated and still have this behaviour then something went sideways in your install.
However...
When I rename a HTML file (or a JPG or PNG file) to 'blablabla.exe' it is recognized by caja as a 'DOS/Windows executable' while MS-Windows .EXE files do have a magic number.
I also tested the other way around. A Windows executable without .exe suffix is still recognized as a MS-DOS/Windows executable until I change the suffix to JPG or PNG in which case it is classified by caja as an image.
This proves that caja does undestand magic numbers but also that it chooses to prioritize filename-suffix over magic number.
This is absolutely a bug if it is agreed by all that a magic number has priority over filename suffix.
The "file" command gives priority to the magic number so caja can at least be called "inconsistent" with the underlying system.
UbuntuMATE and all its kin are living in the Linux/UNIX/POSIX universe.
I fully expect the magic number to have primacy relating to reporting of filetypes, regardless of filename suffix, or conventions used in other universes.
I expect Caja to be driven by the logic of the "file" command, and NOT some unspecified logic which is not inherent to the Linux/UNIX/POSIX community.
Otherwise, we find ourselves at the mercy of the same logic that got the Windows universe into a world of hurt regarding files impersonating as other filetypes. Replicating behaviour that might be applicable in a Windows-like ecology, in order to gain acceptance by that community, is a very, very dangerous path/strategy to pursue.
We chose Linux because its better than Windows. We need to make sure that it can actually support our claims to that effect!
Unfortunately, the current behaviour undermines that claim ... IMHO.