1. Open Writer (same for other apps) 2. Click Save 3. Choose a folder to save in 4. Click Export to PDF 5. Choose a different folder to save PDF in 5. Click Export to PDF again Expected: Last selected folder used for PDF export is shown in file picker Actual: Last selected folder used for Save is shown in file picker
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22c07826d77adf93ada6e17ed6ac531163dd5059 tdf#165228 Don't reuse previous path in save dialog It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/145b44382d8c6efd87832b1fb7a97511da1b3fbf tdf#165228 Don't reuse previous path in save dialog It will be available in 24.8.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/67cffdf1b2872b4bcac657f7bcf63f19c261a5c6 tdf#165228 Don't reuse previous path in save dialog It will be available in 25.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This solution is good just for users who export more often in the same folder, but not the current folder. For users who export more often in the current folder is not a good solution. Could this be made optional from settings? Samuel, please try to simulate both worksflows to see how annoying is for each one. A setting could please both.
Please, do not inflict this on us. Amost always one wants PDFs to be generated side to side to the original document, not where you last saved something. Making it easy to generate PDFs side to side to the original document is what LibO has always done and is what competing products do. This was probably not a bug in the first place, the software was working exactly as intended, but a wishlist item. If you really want something like this please treat it as an enhancement, add the feature that is useful to you without breaking the workflow of others who were relying on the original software behavior. For instance, assure that, exporting to PDF, either: - the file dialog is modified to add a button to quickly select the current document location, so you can default to the last location, or viceversa add a button to quickly select the last location so that you can default to the current document location (might be complicated, given that the software relies on many different toolkits for the save dialog); - the PDF options dialog that appears before the file dialog is augmented with an extra section "Export location" with a tickbox: "Side to side to current document" assuring that the file dialog is not opened at all and that the document is saved side to side to the current document, with the same name and the extension changed to .pdf.
Hello, I'd like to strongly support the request to restore the original behavior — both for Export as PDF and more importantly for Save As... actions. After upgrading to LibreOffice 25.2.2.2 on GNU/Linux Debian 12 (Cinnamon), I was surprised and frustrated to find that using Save As... no longer defaults to the location of the currently opened document, but instead to a previously used folder (often ~/Documents). This leads to a very confusing and error-prone workflow. cf. https://bugs.documentfoundation.org/show_bug.cgi?id=165917#c33 This is not a subtle detail — when working on a new version of a document, you naturally expect the save dialog to open in the same folder. If it doesn't, there's a real risk of saving the new file elsewhere by mistake, and later being unable to find it. It becomes an annoying investigation each time. In my view, this behavior change breaks user expectations, and it cannot be considered an improvement — or even just a preference — without risking serious disruption for many users. I fear this is a case where a well-meant idea about "how it should work" ends up causing real confusion and workflow loss. Please do not impose this new logic as a default. If the intention is to provide flexibility, the ideal solution is to make this behavior configurable, or at least to offer a toggle in the export/save dialog (as discussed above). Thanks again to the developers for all the fantastic work — just hoping we can preserve the usability and predictability we've relied on for so long. Best regards, Serge
@Samuel, can the "context" framework for bug 126665 [1] and the tweak for bug 165228 [2] be reworked to allow the export filter chosen to configure behavior? Is "context" currently per module, or per document? And could it be per export/save filter? E.g. a user wanting to exports to PDF in the current directory can make that choice and have it apply to all their exports to PDF? While their exports to EPub could be assigned to go into last selected? While their Save-as and Save contexts would take defaults, and go to their Tools -> Options -> LO -> Paths defined directories. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/118597 [2] https://gerrit.libreoffice.org/c/core/+/181871
(In reply to BogdanB from comment #4) > This solution is good just for users who export more often in the same > folder, but not the current folder. For users who export more often in the > current folder is not a good solution. Could this be made optional from > settings? I agree with you. I suggest these possibilities in settings: - save in current working folder or - save in last used directory or - ask in which directory to save the file > > Samuel, please try to simulate both worksflows to see how annoying is for > each one. A setting could please both.
Ugh, all my "Save As" documents are ending up in the wrong placem (i.e., not the same folder as the original document). This change is very disruptive.
Me too, I strongly suggest to restore the original behavior...
Hello, I have been working with Libreoffice on Linux installed via Flatpak with no problem. Now I have having this problem with Libreoffice installed in a new system via Flatpak, as before. --------------------------------------------------------- Until today Libreoffice was behaving like this. I have: File A in folder A File B in folder B File C in folder C No matter what I did: if I was working with any other file, before, during and after saving any file, with File A, when creating a new version of File A, the Save As dialog opened up in Folder A, so I could save the new version of File A in Folder A easily. And continue next day with that last version just by going to Folder A if I was working with any other file, before, during and after saving any file, with File B, when creating a new version of File B, the Save As dialog opened up in Folder B, so I could save the new version of File B in Folder B easily. And continue next day with that last version just by going to Folder B if I was working with any other file, before, during and after saving any file, with File C, when creating a new version of File C, the Save As dialog opened up in Folder C, so I could save the new version of File C in Folder C easily. And continue next day with that last version just by going to Folder C -------------------------- But now, in a newly installed system, Libreoffice behaves differently, like this. Let's say the last file I have saved is File C, so I save it on Folder C. Now if I use the dialog Save As for File A or B, as the last file saved was C, saved in folder C, the dialog box Save As for files A or B, is opened on Folder C, as it was the folder where I saved for the last time. This is creating dangerous problems for me, because if I do not notice it, and I have already happened, I have been saving files in the wrong folders. So when I go back to, let's say, Folder A, I am continuing working not with the last version of A, because the last version of A is in the wrong folder. ------------------------------ Please revert the behavior of Save As dialog box to the previous one, which is the one it always has had. Or at least allow us to easily choose which behavior we want for that dialog box. Thanks in advance.
Could this be tweaked to do something like remember the last used folder for each window instead? So, it might work as expected for most users and also support the use case proposed by this bug. Something like this: 1. Window A: Open document A from folder A 2. Window B: Open document B from folder B 3.1 Window A: Export as PDF -> file picker show folder A 3.2 Window A: Choose folder C and export 4. Window B: Save As... -> file picker show folder B 5. Window A: Export as PDF -> file picker show folder C 6. Window A: Open a new document D from folder D 7. Window A: Save As... -> file picker show folder D 8. Window A: Export as PDF -> file picker show folder D 9. Window B: Save As... -> file picker show folder B I don't know if people will prefer Save As and Export as PDF to use the same folder or not. But I think it doesn't matter much for me.
I think this commit also solved this bug. In this case, Samuel, this is a duplicate? Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 tdf#165917 Improve Export directory pre-selection It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yup, I agree fix for bug 165917 fixes this one too.
(In reply to Thorsten Behrens (allotropia) from comment #14) > Yup, I agree fix for bug 165917 fixes this one too. @Thorsten, then could you broker its [1] backport to 25.2? Doesn't seem Samuel has the cycles... or were we hoping for more feedback on master against correction in 25.8? =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/184062
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/446fe1d1b85ee98a4b8146c921e7eea22ed7e3a5 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 25.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-25-2-3": https://git.libreoffice.org/core/commit/041ccc2af2406884f3b1f5efc6bdb51952db5c8c tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 25.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/2490fe156ea14f2ee92fd08e901eed8df9f8c9f4 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 24.8.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-24-8-7": https://git.libreoffice.org/core/commit/beb328011725b3243ab03e8afe26fe2e43ecede5 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 24.8.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The daily of today does NOT solve the problem. While it correctly prepared to "save as" the first opened file into its own folder, it used that same folder when opening another file from a totally different net-drive-directory and trying to "save as" that back again. The same with some file on the same drive, but another directory. used version is: "Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 14; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded"
What are you trying to "remember" ? - revert to what was done before - and what ALL tools do when save-as or Export : use the same directory as the opened document. The current version of LO is a nightmare that spreads files in seemingly random locations. EVERYBODY is rightly complaining and the fix for 24.2 is still not available :-(
(In reply to Andreas Körber from comment #20) > The daily of today does NOT solve the problem. While it correctly prepared > ... > used version is: > "Version: 25.2.2.2 (X86_64) / LibreOffice Community > Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac > CPU threads: 14; OS: Windows 11 X86_64 (10.0 build 26100); UI render: > Skia/Raster; VCL: win > Locale: de-DE (de_DE); UI: de-DE > Calc: threaded" That build would not have the "corrected" behavior. You'd need a nightly of 25.2.3.2 or better a nightly of master against 25.8.0
removing the 25.2.2 target as refactored since
*** Bug 166375 has been marked as a duplicate of this bug. ***