Browser file-ending display error

Hi,
In today's update, I found a bug that may occur in Windows browsers. I haven't tested it on Linux yet.
When selecting the update file (ending with .bin), the browser shows me this:

You use this for the pre-selection:

esp32-firmware/software/web/src/modules/firmware_update/main.tsx

Line 187 in 20fdf4a

accept=".bin"

In my tests, wenn you change this to
accept=".BIN,.bin"
it looks much better:

Which browser am I looking at? Do you have some extensions installed that could cause this?

I've just tested Firefox 128, Chrome 128 and Edge 127 and the filter did work as expected. (to be fair: on Windows 10; the dialog in your screenshot has rounded buttons, so I'm assuming this is Windows 11?)

Chrome 128 with no extensions installed, and you are right, it is Windows 11.

Linux => KDE => Chrome (127)

With Chrome on Windows 11 on my colleague's PC, it's still working:

I'm not fundamentally opposed to changing accept=".bin" to ".bin,.BIN", but

I'd like to see the bug for myself
In other browsers and on other operating systems, the file picker shows entries such as "All supported types" and/or splits *.bin and *.BIN into separate entries, which is strange.
The file type specifiers should be case insensitive: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/accept#unique_file_type_specifiers

The replacement char garbage that you see really confuses me, because this smells like a bug in Chrome. I would have expected to see the same behaviour on our machine.

This is really strange behavior. It's not related to the case sensitivity. For me, it helps if a second value is also specified, such as '.jpg,.bin'. I only tried it with '.BIN,.bin' because that way it only shows '.bin' files. Btw ".bin,.bin" also fix this.
I also tried to change the browser language to English, but the same incorrect behavior persists.

You don't have to fix it for me, I thought it is a global problem.

I know, I know ... my fault is to use Windows ... 😄

I know, I know ... my fault is to use Windows ... 😄

I'm the first to blame Windows for everything, but in this case it's working on two Windows machines :D

I've build a test page, with some more accept-variants: input_file.zip

If you open each one of those file pickers and navigate into the input_file directory:

.bin: is broken as above with garbage characters in the file type selector?
.bin,.BIN: works but calls the selected file type "Benutzerdefinierte Dateien"?
.gif: Do you get the broken behaviour here?
.gif,.png works but calls the selected file type "Benutzerdefinierte Dateien"?
text/html: Do you get the broken behaviour here?
text/html,application/zip works but calls the selected file type "Benutzerdefinierte Dateien"?
application/octet-stream: Do you get the broken behaviour here?
.bin,application/octet-stream: Does this

work?
automatically pre-select .bin?
show up as ".bin,.BIN", not as "Benutzerdefinierte Dateien" in the file type selector?

.bin: is broken as above with garbage characters in the file type selector?

Yes, it is broken as described, and only .bin files are shown for selection.

.bin,.BIN: works but calls the selected file type "Benutzerdefinierte Dateien"?

Exactly

.gif: Do you get the broken behaviour here?

No, it is not broken. This works as expected.

.gif,.png works but calls the selected file type "Benutzerdefinierte Dateien"?

Exactly

text/html: Do you get the broken behaviour here?

No, it is not broken. The file type is labeled as "Benutzerdefinierte Dateien."

text/html,application/zip works but calls the selected file. type "Benutzerdefinierte Dateien"?

Exactly.

application/octet-stream: Do you get the broken behaviour here?

No, it is not broken. I can see all files in the folder, and the file type is "Alle Dateien."

.bin,application/octet-stream: Does this

Yes, it is broken as described, and only .bin files are shown for selection with garbage characters.

By the way, Chrome and Microsoft Edge exhibit the same behavior. Firefox works as expected.