Description: The problem occurs in writer and calc. Please consider that I'm using the german version! I want to "save under", enter a file name and change the filter thereafter. By changing the filter it corrupts the entered filename, e.g. in calc I enter "2025.04.06 testdata". The filter has "ods". When I change the filter to "xlxs" and click on "extend filename automatically" it changes the filename to "2025.04.xlxs" When I do this in writer it behaves the same. Steps to Reproduce: 1. it should be fixed 2. 3. Actual Results: See Description Expected Results: No change of the entered filename after changing the filter and click on "extend filename automatically" Reproducible: Always User Profile Reset: Yes Additional Info: I've just described it... Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 20; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE 25.2.2-1 Calc: CL threaded
And what should happen, when the filename box had "2025.04.ods", and you change from ODS to XLSX? Should it become "2025.04.xlsx" or "2025.04.ods.xlsx"? IMO, this is not a bug. The file extension is just any characters after the last dot; and changing the filter, when "Automatic file name extension" is active, there is no bullet-proof way to know, if the last group of characters was meant to be extension or part of the name. Is there an application, that allows to have extension chosen automatically based on the file type, which does that in a way that you want? We could consider that app's behavior as a potential guideline.
As a potential improvement, the "Automatic file name extension" function could consider the *previous* filter, when deciding if the new extension should be appended to the whole filename, or it should replace the section after the last dot. It could be modified to only replace the section that matches one of the extensions registered for the old filter. The (potential) code pointer is lcl_autoUpdateFileExtension in fpicker/source/office/iodlg.cxx. But IMO, a clear specification of the wanted behavior is needed; asking for UX eval.
(In reply to Mike Kaganski from comment #2) > ... could be modified to only replace the section that > matches one of the extensions registered for the old filter. IOW, only xlxs, csv, html etc. in the name is replaced and any foo, bar, baz will be ignored. I see no harm in this modification, the file naming with dots between date sounds common.
(In reply to Mike Kaganski from comment #1) > And what should happen, when the filename box had "2025.04.ods", and you > change from ODS to XLSX? Should it become "2025.04.xlsx" or > "2025.04.ods.xlsx"? > > IMO, this is not a bug. The file extension is just any characters after the > last dot; and changing the filter, when "Automatic file name extension" is > active, there is no bullet-proof way to know, if the last group of > characters was meant to be extension or part of the name. > > Is there an application, that allows to have extension chosen automatically > based on the file type, which does that in a way that you want? We could > consider that app's behavior as a potential guideline. Hey Mike, sorry for my late reply. I think you did not understand my problem: The file name "2025.04.06 testdata" is changed to only "2025.04.ods" that means the part ".06 testdata" is missed!!! And this change is made when I change the filter... So the origin name of the file must be edited thereafter. And what I expect should be "2025.04.06 testdate.xlxs"
(In reply to Joachim Urmersbach from comment #4) > I think you did not understand my > problem: The file name "2025.04.06 testdata" is changed to only > "2025.04.ods" that means the part ".06 testdata" is missed!!! To the contrary: I understood your problem, but you didn't understand me: from the application point of view, the last part of the file name after last dot is called "file extension". File extension is often three characters (.TXT); it is also often four characters (.DOCX); but it may be arbitrary - and even with spaces. So in your "2025.04.06 testdata", only human can definitely tell, that "06 testdata" is *not* an extension. From application's point of view, when you change file type, the application needs to decide, *why* it *should* change text like "2025.04.ODS" into "2025.04.XLSX" (i.e., replace the part after the last dot), but "2025.04.06 testdata" into "2025.04.06 testdata.XLSX" (i.e., keep the part after the last dot). As I explained in comment 2, there is a viable heuristic that we could use; but that's a heuristic, and comment 1 discusses the original problem that that heuristic could improve.
My expectation would be: - I have given a filename, the extension is not mentioned in the name!!! - the standard extension is odt or ods - I change the filter to xlxs - the filename is never allowed to be changed, whatever the name is and also if there are dots in the name or not. Because the extension is never shown in the filed of the name! So why do you think it is correct behavior to think about and decide whether the part after the dots given in the name mark the beginning of the extension? This is not logical in my opinion...
(In reply to Joachim Urmersbach from comment #6) > My expectation would be: > > - I have given a filename, the extension is not mentioned in the name!!! > - the standard extension is odt or ods > - I change the filter to xlxs > - the filename is never allowed to be changed, whatever the name is and also > if there are dots in the name or not. Because the extension is never shown > in the filed of the name! Your expectation is understood. Comment2 and comment 3 are discussing how we can make that happen. > So why do you think it is correct behavior to think about and decide whether > the part after the dots given in the name mark the beginning of the > extension? Because "the standard extension is odt or ods" is only some *usual convention*, not a law. People call their files very differently; they use "wrong" extensions (like "XLS" for CSV), or completely custom extensions, in their practice. So again: while I myself suggest, that we can improve, by following these "common conventions" (again, see comment 2), I repeat that ".06 testdata" is a *valid extension*, and honestly, the current behavior is technically correct and logical.
Agree with suggestion of comment 2 to provide some logic to recognize previous file name is present *without a well known file extension*--and to simply append extension to that. Presence of a " " in the last part of the file name seems a low hanging test, maybe available with a simple ICU lib word bound test of the established file name?
We discussed the topic in the design meeting. However, using "2025.04.06 testdata" added .odt and changed only this part when switching to other formats on Windows - as expected and recommended. No file extension is shown on Linux Qt/X11. => back to QA
Created attachment 200489 [details] Screencast Windows
The .ods case works both with gtk3 and kf6, but the .xlsx case fails with kf6. Already seen in old versions like 7.0. I found an ancient report, bug 45764 where it is mentioned in 2021 that this KDE issue would be fixed: https://bugs.kde.org/show_bug.cgi?id=431638 "File Dialog does not add the proper extension automatically to saved files if the file name contains dots". I could not find any open relevant KDE bug. This fixed one is a bit related, but specific to a certain mime type: https://bugs.kde.org/show_bug.cgi?id=501085 Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: d896b03b0aefee24bcb5c3c07809e59ff6bf1efa CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
Created attachment 204460 [details] Screencast showing the same behavior in Okular
(In reply to Buovjaga from comment #11) > I found an ancient report, bug 45764 where it is mentioned in 2021 that this > KDE issue would be fixed: https://bugs.kde.org/show_bug.cgi?id=431638 "File > Dialog does not add the proper extension automatically to saved files if the > file name contains dots". This is a slightly different issue, s.a. the test scenario described in the commit fixing it: https://invent.kde.org/frameworks/kio/-/commit/75222ea5d076bec2ed907ffeb65eaa90a522a02a I can also reproduce the same behavior as described in the initial description in Okular, so this behavior is potentially implemented somewhere in Qt or KDE, it seems. Screencast using Okular: attachment 204460 [details] If you consider this a bug, I'd suggest to report that in the KDE issue tracker instead (probably using the Okular example makes the most sense). (Adding an early return in the `lcl_autoUpdateFileExtension` function mentioned by Mike in comment 2 doesn't make a difference, but I didn't investigate more closely. Behavior not reproducible with gen, so it might be that Qt/KDE uses a different/internal code path. ) -> Closing as NOTOURBUG for now as the same behavior can be observed with Okular. Please feel free to reopen in case feedback from KDE developers on a bug reported there suggests this is still a LibreOffice problem.