Bug 119978 - Save dialog incorrectly selects first document in directory and pre-fills the filename with it
Summary: Save dialog incorrectly selects first document in directory and pre-fills the...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.1.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-19 10:10 UTC by Owen Savill
Modified: 2019-04-04 12:39 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Savill 2018-09-19 10:10:58 UTC
Description:
Create a new document, add some words and save it is foo.odf. 
Select Save As, in order to save it as a docx file

The first docx file in the directory is used to populate the file name! Random, annoying and possibly destructive.

Without noticing this I happily selected the Word 2007 - 2019 format as clicked Save. 

The file that was auto selected, e.g. bar.docx, got overwritten! 

Actual Results:
The first document in the directory may get overwritten regardless of the actual name of the file your editing.

Expected Results:
The document with the same name and possibly a different extension should get written to or possibly overwritten if applicable.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
What happened to the Major bug category. I feel this is a major bug as to anyone who doesn't notice this happening as being destructive
Comment 1 Owen Savill 2018-09-19 12:10:18 UTC
The text "The first docx file" should probably read "The first document file" as it pre-fills the name box with this filename before you select the file format.
Comment 2 Jean-Baptiste Faure 2018-09-19 19:19:13 UTC
Not reproducible for me with LireOffice 6.1.1 from Ubuntu PPA under Ubuntu 18.04.

What is your window manager ?

Status set to NEEDINFO, please set it back to UNCONFIRMED once requested
informations are provided.

Best regards. JBF
Comment 3 Owen Savill 2018-09-20 09:16:29 UTC
Hi Jean-Baptiste,

Yes, a previous bug I reported was found to be in the native vs non native save dialog under my desktop environment. I use KDE / Plasma and using the native LibreOffice save dialog as soon as any key was pressed in the filename field it would just autorepeat incredibly fast making it impossible to save any document.

I noticed that there is a small checkbox at the bottom of the save dialog which says "Automatically select filename extension (.docx)". It was checked. When this is unchecked the issue goes away. Seems like an odd feature since it dramatically increases the likelihood of accidental file overwriting. Also when I looked closer there are two files whose names which start with letters closer to the start of the alphabet so how it selected the particular file it does to be the file it auto selects I don't know. 

I also assume that since this is a very specific save option, i.e. .docx, that I am using the native LibreOffice save dialog.

(In reply to Jean-Baptiste Faure from comment #2)
> Not reproducible for me with LireOffice 6.1.1 from Ubuntu PPA under Ubuntu
> 18.04.
> 
> What is your window manager ?
> 
> Status set to NEEDINFO, please set it back to UNCONFIRMED once requested
> informations are provided.
> 
> Best regards. JBF
Comment 4 Xisco Faulí 2018-10-08 15:26:05 UTC
Do you reproduce it if you call LibreOffice from the command line like 'SAL_USE_VCLPLUGIN=gtk soffice' ?
Comment 5 Owen Savill 2019-04-04 12:26:30 UTC
This appears to be fixed now, when Save As is selected the current filename is selected even in the native Plasma file dialog.
Comment 6 Xisco Faulí 2019-04-04 12:39:29 UTC
(In reply to Owen Savill from comment #5)
> This appears to be fixed now, when Save As is selected the current filename
> is selected even in the native Plasma file dialog.

Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.