Created attachment 185462 [details] A Screencast That Demonstrates The Problematic Behaviour Reproducing Via Firefox's Implementation Of The KDE Portal # SUMMARY Capitalising the file extension of a to-be-downloaded file does not cause the lower-case version of the existent extension to not be appended. To elaborate, when I save a file (whose suggested filename may be `ExampleFile.pdf`), if I replace its existent, lower-case file extension (`.pdf`) with an extension of different case (of which `.PDF` is an example), the original file extension is appended: the aforecited example would become `ExampleFile.PDF.pdf`. # STEPS TO REPRODUCE ~~~sh #!/usr/bin/env sh touch pdf_file.pdf okular pdf_file.pdf ~~~ Thereafter: 1. Save it as a new filename, which solely `.pdf` replaced with `.PDF`. 2. Examine the resultant filename. # OBSERVED RESULT The resultant filename shall be `pdf_file.PDF.pdf`. # EXPECTED RESULT The resultant filename should be `pdf_file.PDF`. # SOFTWARE/OS VERSIONS > ~~~ > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.4.5 > KDE Frameworks Version: 6.18.0 > Qt Version: 6.9.2 > Kernel Version: 6.16.8-200.fc42.x86_64 (64-bit) > Graphics Platform: Wayland > ~~~ # ADDITIONAL INFORMATION Originally reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1991515#c4.
Created attachment 185463 [details] A Screencast That Demonstrates The Problematic Behaviour Not Reproducing Via Firefox's Implementation Of GTK's (Embedded) Alternative
I am unable to repro this, I tried to save PDF from Firefox and changed the file ending to .PDF instead of .pdf It seemed to save it fine without any extras. Do you use Firefox from flatpak? I tried it with chromium flatpak too but could not repro. Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.9-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
Created attachment 185477 [details] A Screencast That Demonstrates The Problematic Behaviour Reproducing Via Okular's File Chooser (In reply to Akseli Lahtinen from comment #2) > I am unable to repro this, I tried to save PDF from Firefox and changed the > file ending to .PDF instead of .pdf > It seemed to save it fine without any extras. Better yet, try it with a KF6 application, like https://koji.fedoraproject.org/koji/rpminfo?rpmID=44538539: > ~~~ > sh-5.2$ rpm -qi $(rpm -qf $(command -v okular)) > Name : okular > Version : 25.08.1 > Release : 1.fc42 > Architecture: x86_64 > Install Date: Sat 27 Sep 2025 14:28:17 BST > Size : 7368651 > Signature : RSA/SHA256, Thu 25 Sep 2025 13:21:34 BST, Key ID c8ac4916105ef944 > Source RPM : okular-25.08.1-1.fc42.src.rpm > Build Date : Thu 25 Sep 2025 01:45:59 BST > Build Host : buildvm-x86-20.rdu3.fedoraproject.org > Packager : Fedora Project > Vendor : Fedora Project > URL : https://www.kde.org/applications/graphics/okular/ > Bug URL : https://bugz.fedoraproject.org/okular > ~~~ I've attached a screencast that demonstrates that it reproduces there, too. > Do you use Firefox from flatpak? I tried it with chromium flatpak too but > could not repro. I utilise https://koji.fedoraproject.org/koji/rpminfo?rpmID=44588843: > ~~~ > sh-5.2$ rpm -qi $(rpm -qf $(command -v firefox)) > Name : firefox > Version : 143.0.3 > Release : 1.fc42 > Architecture: x86_64 > Install Date: Wed 01 Oct 2025 18:30:40 BST > Size : 262129245 > Signature : RSA/SHA256, Tue 30 Sep 2025 20:15:33 BST, Key ID c8ac4916105ef944 > Source RPM : firefox-143.0.3-1.fc42.src.rpm > Build Date : Tue 30 Sep 2025 08:21:51 BST > Build Host : buildvm-x86-05.rdu3.fedoraproject.org > Packager : Fedora Project > Vendor : Fedora Project > URL : https://www.mozilla.org/firefox/ > Bug URL : https://bugz.fedoraproject.org/firefox > ~~~
Why would it be .PDF? .PDF is not the same as .pdf on most Linux file systems and the mimetype definition is *.pdf.
(In reply to Harald Sitter from comment #4) > Why would it be .PDF? .PDF is not the same as .pdf on most Linux file The filesystem does not care about the file extension. > systems and the mimetype definition is *.pdf. That is incorrect. It is "application/pdf", and IANA Media Type definitions, excepting solely parameter values (like charsets) are case-insensitive.
I am sure the file system cares seeing as the extension is part of file name. And I have just checked, the mimetype definition most definitely lists *.pdf but no *.PDF in sight.
(In reply to Harald Sitter from comment #6) > I am sure the file system cares seeing as the extension is part of file > name. Then, please elaborate on what you mean by "care about" in this context. I'm trying not to be an annoyance by attempting to infer what such a vague statement means, but you've provided me with little to work with. And I have just checked, the mimetype definition most definitely lists > *.pdf but no *.PDF in sight. I've just informed you that Media Types are case-insensitive. That is why not every particular case possibility is listed, just as is true for DNS. If you would like an authoritative citation, I'll provide one. However, being ignored isn't particularly pleasant. Additionally, your RegEx is nonsensical – no Media Type ends with a period. They are not file extensions, yet you appear to conflate them. Please don't be so trigger-happy with the triage, because I'm not going to re-open it myself, and getting someone else to review it would be an arduous process.
media types may be case insensitive but file extensions surely not
(In reply to David Redondo from comment #8) > media types may be case insensitive but file extensions surely not Based upon what? I ask because, as my own knowledge, and the undermentioned citations corroborate, filesystems like FAT (and VMS's ODS-3) store all filenames as upper-case, [^1] [^2] and all Win32 filesystem APIs are case-insensitive. This matters to us, because I've yet to encounter any software in my lifetime that would treat `.PDF` as an entirely different file type to `.pdf`. I am certain you've not, either. This is especially because, outside of Windows (that is, on all XNU/Darwin and Linux-based OSes), file association is performed my Media Type! In that context, special-casing file extensions in solely KDE's file chooser portal doesn't make any sense, when it's not a determiner that this DE uses. [^1]: https://lists.debian.org/debian-user/2009/09/msg00443.html [^2]: https://superuser.com/revisions/862283/2#:~:text=The%20original%20FAT%20file%20systems%20actually%20stored%20the%20files%20names%20(and%20extensions)%20as%20all%20caps%2C%20regardless%20of%20how%20you%20entered%20them%20(making%20it%20'case%2Dinsensitive'%2C%20but%20not%20'case%2Dpreserving'). Perhaps, explaining my rationale is more convincing: I often need to download a file with a specific filename, so that it can be submitted with a specific filename. I'm going to need to rename it, because the person requesting that file wants it with an upper-case file extension. Making me rename it is nonsensical, as is appending another, redundant file extension (because file extensions are redundant on Linux anyway; I'm adding the extension for Windows users).
(In reply to Roke Julian Lockhart Beedell from comment #9) > because > the person requesting that file wants it with an upper-case file extension. We are not going to add insensitivity code because some person feels the need to want file extensions to be in capital letters, when by your very argument it does not matter what case they are in.
> file association is performed my Media Type! Not even wrong. https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/data/freedesktop.org.xml.in?ref_type=heads
(In reply to Harald Sitter from comment #10) > We are not going to add insensitivity code because some person feels the > need to want file extensions to be in capital letters, when by your very > argument it does not matter what case they are in. Have you never needed to upload a file with a specific filename, or downloaded one with a capitalised extension? AOSP 15 (API 35)'s `com.google.android.documentsui/com.android.documentsui.picker.PickActivity`, Windows 11 24H2's WinForms and WinUI3 `FilePicker`, and GTK 4.22's file chooser (even outside of GNOME 48) all support this. Considering that their developers put the time into it, even regardless of what you think of my rationale, there must be a reason to implement it.
Patches welcome I guess.
(In reply to Harald Sitter from comment #13) > Patches welcome I guess. Thanks a lot. Shall do when I'm able to write CPP... Can I change it to RESOLVED LATER, or similar, so I don't forget?