Description: Writer: 'Save As' using the system dialogue style sometimes shows at the top just a filename (preselected) and sometimes a name plus file type (the type being preselected). Circumstances are not clear: renaming a file (including moving to a different directory) before opening can change the behaviour. Normally no type is displayed, and 'Save As' to a non-odf file gives a saved file with the correct type. When the type is displayed, the file will always be saved with that type, even if it is inapproriate for the format. Steps to Reproduce: 1.Sorry! There seems no way to produce this to order. (Yes, I know :-{ ) 2. 3. Actual Results: 'Save As' shows a file type in the filename box Expected Results: No file type is expected to be shown Reproducible: Sometimes User Profile Reset: Yes Additional Info: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3 Calc: threaded (I know this also happens at least back to 6.4.7.2. With an affected file on a shared NFS filesystem, the problem shows up on all machines that can access that file provided the mountpoint is the same. Changing mountpoint can make the issue not appear although the file remains unchanged. eg mounting my nfs home on /mnt will 'fail' for a particular file, while remounting say on /tmp/zzz works ok. On a slower machine, a screencapture video shows the correct dialogue (name only) is shown first, then replaced quickly by an incorrect one (name plus type) (Screenshots to follow)
Created attachment 188961 [details] Save As with wrong behaviour See the top line with the file name and type
Created attachment 188962 [details] Save As with expected behaviour Shows just the file name (preselected)
I can reproduce with GNOME 3.36.8, when switching from the current folder to another, then back to the folder where the file has the same name. At this stage, instead of having the first part of the filename highlighted, it's the extension that gets highlighted. For example: 1. Open Writer 2. Save file as "test.odt" in Downloads folder 3. Ctrl + Shift + S: see that "test" is highlighted in the filename field 4. Switch to Home folder, and back to Downloads folder Result: ".odt" is highlighted. Do these steps reproduce if consistently for you too, Mike? Same in recent master build and 6.2.0.3. Not reproduced in 6.1, with gtk2 VCL plugin. I thought it might have been a GNOME bug but I tested the same scenario in other apps that use the DE file manager and could not reproduce (gedit, gnumeric). However, OnlyOffice shows a similar behaviour: if the file name exists already, the extension is highlighted instead of the name. Caolán, any insight into if we have any control over that? Or a definite "not our bug"? See also bug 142476.
I'm fairly confident that it is not our doing. We set the initial name and it is not us that is adding the suffix when visiting a dir after the initial name is set and the dir has a file which will match the initial name and default filter suffix. I think I can reproduce it with gedit which defaults to showing "Untitled Document 1" as the filename to save. a) touch ~/Downloads/"Untitled Document 1.txt" b) gedit c) save file chooser says "Untitled Document 1" d) pick "Music" or some random dir and it stays as "Untitled Document 1" e) pick "Downloads" which has the "Untitled Document 1.txt" from a) and it also goes to "Untitled Document 1.txt" with ".txt" selected like LibreOffice does. So I think it is built-in gtk file chooser behaviour outside of our control.
(In reply to Caolán McNamara from comment #4) > I'm fairly confident that it is not our doing. We set the initial name and > it is not us that is adding the suffix when visiting a dir after the initial > name is set and the dir has a file which will match the initial name and > default filter suffix. > > I think I can reproduce it with gedit which defaults to showing "Untitled > Document 1" as the filename to save. > > a) touch ~/Downloads/"Untitled Document 1.txt" > b) gedit > c) save > file chooser says "Untitled Document 1" > d) pick "Music" or some random dir and it stays as "Untitled Document 1" > e) pick "Downloads" which has the "Untitled Document 1.txt" from a) and it > also goes to "Untitled Document 1.txt" with ".txt" selected like LibreOffice > does. > > So I think it is built-in gtk file chooser behaviour outside of our control. You're right, I see it with gedit too now. Thanks for the input, I agree with "not our bug".
I'm not so sure, although I see the noted behaviour with gedit as well. I currently have my networked home directory with two files: Assnm7 x3 food.odt Assnm7 x3 food (copy).odt Nothing else with an even vaguely similar name. They behave differently when opened and "Save As" is invoked. The 'copy' highlights the file extension, the original highlights the name and shows no extension. This does not seem to parallel the gedit behaviour. Although I'd not be surprised at some arcane code within gtk. Whether or not it's an LO bug, there is the potential of data loss. Normally, working with a .odt source and wishing to export, say, a .docx, 'Save As' will add the correct extension. If it's in "show the extension" mode, then the user *must* remember to change this, otherwise there's a prompt about overwriting an existing file -- easily misunderstood if the user already has an old .docx he wants to lose, and the source .odt will be overwritten with a .docx having the wrong extension. I've left this marked as "resolved", but have to say I'm not totally happy.
(In reply to Mike Scott from comment #6) > I'm not so sure, although I see the noted behaviour with gedit as well. > > I currently have my networked home directory with two files: > Assnm7 x3 food.odt > Assnm7 x3 food (copy).odt > > Nothing else with an even vaguely similar name. > > They behave differently when opened and "Save As" is invoked. The 'copy' > highlights the file extension, the original highlights the name and shows no > extension. I don't see this with GNOME 3.36.8 and a recent master build of LO. Both have the filename highlighted with no extension. In any case, my recommendation is to open a bug report on GNOME's side: https://gitlab.gnome.org/groups/GNOME/-/issues