search

Tinkerforge / esp32-firmware

Firmwares for ESP32 Brick and ESP32 Ethernet Brick (including firmwares for WARP/WARP2 Charger, WARP Energy Manager)
https://www.tinkerforge.com/en/doc/Hardware/Bricks/ESP32_Ethernet_Brick.html
26 stars 20 forks source link

Browser file-ending display error #366

Open breitsi opened 2 weeks ago

breitsi commented 2 weeks ago

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: image

You use this for the pre-selection: https://github.com/Tinkerforge/esp32-firmware/blob/20fdf4a002a4c0f281e510bc22b20dedaabcc5b4/software/web/src/modules/firmware_update/main.tsx#L187

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

rtrbt commented 2 weeks ago

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?)

breitsi commented 2 weeks ago

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

breitsi commented 2 weeks ago

image Linux => KDE => Chrome (127)

rtrbt commented 2 weeks ago

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

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

  1. I'd like to see the bug for myself
  2. 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.
  3. 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.

breitsi commented 2 weeks ago

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 ... :smile:

rtrbt commented 1 week ago

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:

breitsi commented 1 week ago

.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.