Description: I'm using Libreoffice Windows to save files and export them to PDF. With current version whenever I ask to create a PDF (PDF button in the toolbar, not the export function) and the saving window pops up, if in the selected folder (the one where the open document is saved, contains other PDF files, the first one is highlighted. Even if the File name of the file to be created corresponds to the same name of the open file, if you click on Export it will overwrite the highlighted file. The selection of a file in the folder should be removed so that it will save a new file with the name in the File Name field without overwriting other files. Steps to Reproduce: 1. Open a writer document from a folder where a PDF file is already present 2. be sure to have set the LibreOffice dialogue windows for opening/saving (settings) 3. Click on the PDF creation button in the toolbar 4. the pdf fle in the folder will be highlighted, the name of the opened file will be in the File Name field. 5. Click on Export, it will ask to overwrite the highlighted file. Actual Results: It won't use the File Name to save the exported PDF file but will overwrite an existing PDF file. Expected Results: It should create a new file with the name indicated in the File Name field or overwrite it. Reproducible: Always User Profile Reset: No Additional Info: Nothing else.
I don't understand. Please attach screenshot or screencast.
Created attachment 159298 [details] Bug Writer PDF creation Here you can see that when you ask to export to PDF using the toolbar button and you use the Openoffice dialogue boxes for Opening/Saving, the first PDF file inside the saving folder (which is the same folder where the opened writer document is saved in) is highlighted and even though the name in the File Name field is the correct one, it will overwrite the highlighted PDF. You have to click on the File Name field to save in the new file, or at least in the correct file. This was not so before the recent updates. It causes problems because you are used to click on the PDF button and export and you don't realize you are overwriting another file instead. I hope it is clear now.
[Automated Action] NeedInfo-To-Unconfirmed
Thank you for reporting the bug. I can not reproduce the bug in Version: 6.4.2.2 (x64) Windows 10.0 Build 18363 The PDF tool bar icon will highlight another file in the location which you are trying to save, possibly as an option to over-write. All you need to do is click off the highlighted file and it saves a new file with its correct corresponding name without over-writing. I don't believe this is a bug. I think this is intentional functionality that could perhaps be improved upon. I agree that it might now be the best idea to pre-highlight to be over-written.
If you don't use LibreOffice dialog, the file name will be highlighted. Is that the expected behaviour also for the LibreOffice dialog? Behaviour should be the same, so I would consider this as a bug.
It seems to be a severe general problem. See my bug 132107 where "Save as..." is used to store an .odt file. @Adam: This is a bug because in the dialog the true filename is given. But LO ignores it and uses the first(?) filename in the directory. This can ruin careers (as in my scenario), might cost lots of money or even lifes.
(In reply to murliwurli from comment #6) > It seems to be a severe general problem. See my bug 132107 where "Save > as..." is used to store an .odt file. > @Adam: This is a bug because in the dialog the true filename is given. But > LO ignores it and uses the first(?) filename in the directory. This can ruin > careers (as in my scenario), might cost lots of money or even lifes. Thank you for recognizing this as a sever bug. When is it schedule to be solved?
Most important is search before reporting or confirming. Questions "when will be solved" are useless and annoying. When you code it or find someone who will. I consider this a duplicate of bug 130505. All duplicates have the same root cause: 1st entry in dialog is marked and selected (for save as, PDF export etc.), regardless of what's in the filename. *** This bug has been marked as a duplicate of bug 130505 ***