Description: Instead of using the default source directory of an opened file to "save as" and "export to pdf" in the same source folder, LibreOffice changes its behavior, and whereas the document has been saved or not, sometimes uses the source folder, sometimes the last folder used for "save as" or "export to pdf", which can be different ! Steps to Reproduce: Hi, regarding the discussions about the new feature introduced temporarily in version 25.2.2 with "Saves as" and "Export to pdf" proposing by default not the current same folder as the one containing the original opened file, but the last folder used for each operation "Save as" and "pdf export", version 25.8 aimed to put a new behavior : https://bugs.documentfoundation.org/show_bug.cgi?id=165917#c48 When calling an Export dialog (PDF, epub, ...) the following folder will be preselected: For stored documents: * Current document directory * If another directory was chosen for the export, that directory will be preselected for subsequent exports (stored only during runtime - per document) For unstored documents: * The last used export directory is restored (last used in unsaved doc) But it doesn' t work like this for me in LO 25.8.0.2 on Ubuntu 25.10 (development version) Actual Results: The way LO handles "Save as" and "Export pdf" is far worse now than the modified behavior introduced in version 25.2.2, because LibreOffice doesn't act identically on a same document regarding the chronological order : Simple case: I open a LO document in folder A 1- Without modifying it, I click on "Save as", LO shows me on the window by default the same folder A, if I click then on "Export to pdf", the same - LO shows me by default folder A 2- I write on the document - modify it and, WITHOUT saving it, again if I click on "Save as", LO shows me on the window by default the same folder A, if I click then on "Export to pdf", the same - LO shows me by default folder A. Until now, logical, perfect and the same behavior as before 25.2.2 3- I save the same document (Ctrl-S or "Edit - Save", not "Save as"), it overwrites the file in folder A, I let it opened and again click on "Save as" → this time LO shows me on the window by default the folder B, and if I click on "Export to pdf", LO show me by default folder C * * if the last time the folders when I last "saved as" or "exported as pdf" documents were not the same (because I don't export to pdf all the documents I open, modify and save). So, instead of having all my LO and pdf files for this specific document in the same original folder, I now have files in 3 different folders - a complete mess ! And open a document, modify it, save it, then export to pdf (in this order) is a very common task, I do it every day for dozen of files in many different sub-folders. This behavior, which changes for a SAME opened document whereas it has been saved or not, is completely un-logical and unexpected. Expected Results: It introduces a major change, without explanation, on a major function - saving and exporting files, which breaks with the previous 20 years and the behavior of other software. For example, if I open an image with Gimp, I modify it, save the xcf then export in png, Gimp always proposes me by default the source directory where the original image is stored.And also if I open and work on many images at the same time, in different (sub)-folders, coming from one to others: each time save and export are proposed for each image in their respective current same origin folder. Like I explained just above, LibreOffice not only behaves differently regarding the situation, but worse: for a SAME opened document, it doesn't act identically and changes the default "save as" / "export to pdf" folder even while using a single file, depending on whether or not it has been saved (Ctrl-S). The change introduced in 25.2.2 was questionable, but at least in my memory it was consistent. Now it's a complete garbage in my Files explorer: every day I open, sometimes simultaneously, many odt and calc files, that I modify, save, export in pdf, then re-modify again, coming back from one to another, sometimes after having closed and reopened them, sometimes after having let them opened between the changes. So: Sometimes LO proposes me the source directory by default, sometimes the last folder where I "Saved as" or "exported to pdf" - folders which can be different, and more important, LO changes this last folder many times in the same day - when I notice on the window opened for saving / exporting to pdf and puts the export in the same current folder as the source file, it changes the "last folder used" for the following ones… ! As I don't notice every time - I'm used to save / export to pdf and expect the pdf created / replaced in the same current source folder, it happens that: for some documents I have the odt / calc source in folder A, updated saved as odt / calc in folder B, exported pdf in folder C. And sometimes with multiple copies because those initially on folder A still exist. So when I work on many projects / files on many different sub-folders, a big work is then necessary to reorganize all of them and move on the right origin folders, with a particular attention to replace in folder A with the most recent version ! It's completely unmanageable. :( Reproducible: Always User Profile Reset: No Additional Info: If the option to have an unique directory for all "saved as" and "exported to pdf" files - folders which can be different for each action - is useful for some people, it should be introduced as an option in the settings, not activated by default, and not change in LO version update. I don't understand if it works as intended, if yes how could have such an idea been implemented, or if it doesn't and if it's a bug ?… Thanks in advance for your help and for your great work on LibreOffice !
I test now 26.2, which is somehow similar with 25.8 at this moment. - Restart in Safe Mode. For stored documents: (saved on Desktop) * Current document directory (exported on Desktop) * If another directory was chosen for the export, (Pictures) that directory will be preselected for subsequent exports (stored only during runtime - per document) (---> Pictures) For unstored documents: * The last used export directory is restored (last used in unsaved doc) ----> Documents (linux) Seems ok on linux. But I remembered I tested 25.8 version on Windows and was not ok, so I come back to 25.2. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6204dfeb53aefbc4de1c82a6bfc2f6903565f5c1 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Xavier, please try to reset to factory settings, because some settings can interfere from the last version with the new version. And test again all your tests. ---> Help - restart in safe mode - and check the 2 options from factory settings
Hi, I restarted in safe mode, checked the 2 options from factory settings and reset them. Then I open a LO odt document D1 in folder A 1- Without modifying it, I click on "Save as", LO shows me on the window by default the same folder A, if I click then on "Export to pdf", the same - LO shows me by default folder A 2- I write on the document - modify it and, WITHOUT saving it, again if I click on "Save as", LO shows me on the window by default the same folder A, if I click then on "Export to pdf", the same - LO shows me by default folder A. Until now, logical, perfect and the same behavior as before 25.2.2 3- I save the same document (Ctrl-S or "Edit - Save", not "Save as"), it overwrites the file D1 in folder A, I let it opened and again click on "Save as" → this time LO shows me on the window by default the folder "home/Documents", I change to save it on folder A (overwriting the previous one here), and then if I click on "Export to pdf", LO also shows me by default "home/Documents", I export it in pdf in a folder B. So here, even after having reset the factory settings, there is a bug: LibreOffice proposes me a different directory than its source for a stored document, after I modified it, saved it and without closing it, tries "Save as" and "Export to pdf". First problem. On your tests, have you done my N° 3 manipulation ? Here comes the problem and the inconsistent behavior on a same document: LO considers the document as unstored if it has been opened and saved with "Edit - Save" command, it should still be treated as a stored document. 4- I open a odt document D2 on folder C. Without modifying it, I click on "Save as", LO shows me on the window by default the same folder C, if I click then on "Export to pdf", the same - LO shows me by default folder C 5- I write on the document - modify it and, WITHOUT saving it, again if I click on "Save as", LO shows me on the window by default the same folder C, if I click then on "Export to pdf", the same - LO shows me by default folder C. 6- I save the same document (Ctrl-S or "Edit - Save", not "Save as"), it overwrites the file D2 in folder C, I let it opened and again click on "Save as" → this time LO shows me on the window by default the folder A (the last used for "save as" with Document D1), and if I click on "Export to pdf", LO shows me by default the folder B (the last used for export with D1, different) ! So here if I'm not vigilant I can begin to have origin D2 document on folder C, updated "saved as" D2 document on folder A, and pdf exported on folder B. One document, 3 files, 3 folders - a garbage ! So I confirm the bug on Ubuntu and LO 25.8.0.2…
It is not only a mess, it also not the way it is intended and documented, according to https://bugs.documentfoundation.org/show_bug.cgi?id=165917#c48 To my understanding, the above documentation requires, in that order: * If a folder was explicitely selected in an earlier "export as" in the same session for the same document, then that folder should be the default for "export as". * Else, if the document was newly created (not loaded) and was never saved or exported anywhere, then the folder used for the last "export as" (globally for any document) should be the default for "export as". * Else, in all other cases, the folder where the document was last loaded from, or saved to by "save", or saved to by "save as" (i.e. the current document folder) should be the default for "export as". * This behaviour remains the same no matter if the document was modified or not since last being loaded, saved or exported. Correct me if I'm wrong. This behaviour makes sense to me, that's what we want. So the required/desired/documented behaviour is obviously different from the behaviour observed here.
(In reply to Klaus Kusche from comment #4) > It is not only a mess, it also not the way it is intended and documented, > according to https://bugs.documentfoundation.org/show_bug.cgi?id=165917#c48 Hi, yes the way it is intended sounds more logical, but it's not what I get on LO 25.8.0.2 in Ubuntu 25.10 From what I've observed, the problem occurs here: > Else, in all other cases, the folder where the document was last loaded > from, or saved to by "save", or saved to by "save as" (i.e. the current > document folder) should be the default for "export as". > This behaviour remains the same no matter if the document was modified or > not since last being loaded, saved or exported. What Lo doesn't respect in my case is the "or saved to by "save" → here, after having opened, modified the document and "saved" (not saved as) and let it opened, LO treats it like an unstored document, instead of continuing exporting (save as and/or pdf) in the same current source directory…
I tested now like this: I reset to factory settings 25.2 instalation and saved a new file in Downloads. - Save the file, and export as PDF - destination is the same folder, OK. - reopen the file, change the export to Desktop. Ok. - not closing the file, and export again - Downloads. NOT OK. I reset to factory settings 25.8 instalation and saved a new file in Downloads. - Save the file, and export as PDF - destination is Documents, NOT OK. - reopen the file, change the export to Desktop. Ok. - not closing the file, and export again - Desktop. OK. Version: 25.8.0.4 (X86_64) Build ID: 48f00303701489684e67c38c28aff00cd5929e67 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
I use 90% of time export into the same folder, and if this is not working as expected, I can NOT use 25.8 version. I will stay with 25.2.
Unfortunately, this bug is either still present or is a regression in Version: 25.8.1.0.0+ (X86_64) / LibreOffice Community Build ID: 150bf27c032f615453df8d5da71d86fa767c30de CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-ZA (en_US.UTF-8); UI: en-US Calc: CL threaded Even though I opened a Draw file from my hard drive, the PDF export is saved into my home directory.
This is also true for Writer.
For me, too, this is a blocker / showstopper for 25.8.x ! And it is a regression newly introduced in 25.8.x, because 25.2.5.2 works correctly, or at least works in a way which is much better. Could we *please* have an emergency fix for 25.8 ?! Or at least a rollback to the correct code in 25.2.5.2 ?
Please fix this regression so that 'Export' and 'Save as' always appear in the same folder as the original file. This worked correctly in version 25.2.3.
I have an important mention here: I reset to factory settings 25.8 instalation and saved a new file in Downloads. - Save the file, and export as PDF - destination is Documents, NOT OK. BUT, if the file is already in Downloads and I reopen an existing file it will be exported in Downloads, that is correct, but not when it is saved for the first time. So, just the exception here it is not working, the case when the edited document is saved in a certain folder and exported to PDF before closing. - reopen the file, change the export to Desktop. Ok. - not closing the file, and export again - Desktop. OK
Here are the results of my test with version 25.8.0.3 with a new profile. Create a document and save it into its own folder. Without closing the first document, now create a new document and save it in a different folder. Go back to the first document, and now do a Save As or a Save a Copy. Instead of bringing up the path for the first document, it will bring up the path for the second document. Now try to export as a PDF. It will now try to put it into the Documents folder instead of properly being with the first document. Why in the world should I have to find my original directory where I stored the original source document? Now insert an image. But say you want to save that image as a separate file but with the source document so that you can track what was used where. Right click on it, and where does it try to save it? In the Documents folder also. Go ahead and do a Save a Copy of the first document to maybe a.docx file in the same directory as the source file. Now go to the second document and do the same thing. Where does it try to save it? In the directory for the first document. I can confirm that this regression from the behavior in 25.2.5 is a total disaster. Please fix.
(In reply to Klaus Kusche from comment #10) > Para mim também, isso é um obstáculo/obstáculo para o 25.8.x! > > E é uma regressão recentemente introduzida no 25.8.x, > porque 25.2.5.2 funciona corretamente, > ou pelo menos funciona de uma maneira muito melhor. > > Poderíamos *por favor* ter uma solução de emergência para 25.8?! > > Ou pelo menos um retorno ao código correto em 25.2.5.2? This issue also showed up in version 24.8.6.2
*** Bug 168104 has been marked as a duplicate of this bug. ***
*** Bug 168119 has been marked as a duplicate of this bug. ***
Same issue here on Windows 11 LO 25.8.0.4 Release. Just updated yesterday and this regression returned. This was an issue several months ago and was resolved, but the recent update has broken it again.
*** Bug 168129 has been marked as a duplicate of this bug. ***
Description: in recent versions I have been getting a random error behavior - when you have a document open in LibO and you want to use Save As or export to pdf the file dialog opens in a directory where previous document was saved. I tried 25.8.0.3 and it behaves that way randomly. Sometimes it offer the right directory, sometimes previous. I cannot identify the pattern. I went back to 25.2.3.2 which, for me, lack this bug. Steps to Reproduce: 1. save as (export to pdf) 2. file dialog opens Actual Results: Offers previous opened files directory, not directory of the file being saved as. Expected Results: Should offer directory where is file, which I want "save as" located. Reproducible: Always User Profile Reset: Yes Additional Info: This bug appears in random versions since 25.2.3.2 where is absent.
*** Bug 168195 has been marked as a duplicate of this bug. ***
Same issue here on Windows 11 LO 25.8.1.1 Release. I have updated from 25.2 channel and this regression returned. This was an issue several months ago and was resolved, but the recent update has broken it again. Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 32; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded Jumbo
Regression introduced by commit 22c07826d77adf93ada6e17ed6ac531163dd5059 [log] author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 09:55:04 2025 +0100 committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 12:03:19 2025 +0100 tree 3fe35f67429c1c675c2ef5e582f463fdd1ec131a parent 49407a8723574f93cf07b807fa536b254da5db61 [diff] tdf#165228 Don't reuse previous path in save dialog @Samuel, now that commit 3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 [log] author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Fri Apr 11 18:21:37 2025 +0200 committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Sat Apr 12 08:15:55 2025 +0200 tree d1c47e62030959ff4ddfb672810c6b291fa74546 parent 7fac8458e35620b9855cc6c68a9675159a849b65 [diff] tdf#165917 Improve Export directory pre-selection is in place, would it make sense to revert 22c07826d77adf93ada6e17ed6ac531163dd5059 in order to fix this issue?
I made the text again, I hope more clear. ---------- I reset to factory settings 25.2 installation: - I saved a new file in Pictures (it is important not to be Documents, could be default location for program and affecting testing). Now export as PDF - destination is the same folder, OK. - Close and reopen the file, change the export to Desktop. It is ok (because I made the decision). - Do not close the file, but export again - Downloads. NOT OK. (¨If another directory was chosen for the export, (Pictures) that directory will be preselected for subsequent exports)¨ this is the bug in 25.2 ----------------------- I reset to factory settings 25.8 installation: - I saved a new file in Pictures (it is important not to be Documents, could be default location for program and affecting testing). Now export as PDF - destination is Documents, NOT OK. (For stored documents: * Current document directory) - Close and reopen the file, change the export to Desktop. It is ok (because I made the decision). - Do not close the file, but export again - Desktop. OK. (¨If another directory was chosen for the export, (Pictures) that directory will be preselected for subsequent exports)¨ this is the bug in 25.2
(In reply to Xisco Faulí from comment #22) > Regression introduced by > > commit 22c07826d77adf93ada6e17ed6ac531163dd5059 [log] > author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 09:55:04 > 2025 +0100 > committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 > 12:03:19 2025 +0100 > tree 3fe35f67429c1c675c2ef5e582f463fdd1ec131a > parent 49407a8723574f93cf07b807fa536b254da5db61 [diff] > > tdf#165228 Don't reuse previous path in save dialog > > @Samuel, now that > > commit 3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 [log] > author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Fri Apr 11 18:21:37 > 2025 +0200 > committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Sat Apr 12 > 08:15:55 2025 +0200 > tree d1c47e62030959ff4ddfb672810c6b291fa74546 > parent 7fac8458e35620b9855cc6c68a9675159a849b65 [diff] > > tdf#165917 Improve Export directory pre-selection > > is in place, would it make sense to revert > 22c07826d77adf93ada6e17ed6ac531163dd5059 in order to fix this issue? Sure, can you test that after reverting bug 165228 does not reappear? If that's the case, go ahead with reverting it.
(In reply to Samuel Mehrbrodt from comment #24) > (In reply to Xisco Faulí from comment #22) > > Regression introduced by > > > > commit 22c07826d77adf93ada6e17ed6ac531163dd5059 [log] > > author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 09:55:04 > > 2025 +0100 > > committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 > > 12:03:19 2025 +0100 > > tree 3fe35f67429c1c675c2ef5e582f463fdd1ec131a > > parent 49407a8723574f93cf07b807fa536b254da5db61 [diff] > > > > tdf#165228 Don't reuse previous path in save dialog > > > > @Samuel, now that > > > > commit 3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 [log] > > author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Fri Apr 11 18:21:37 > > 2025 +0200 > > committer Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Sat Apr 12 > > 08:15:55 2025 +0200 > > tree d1c47e62030959ff4ddfb672810c6b291fa74546 > > parent 7fac8458e35620b9855cc6c68a9675159a849b65 [diff] > > > > tdf#165917 Improve Export directory pre-selection > > > > is in place, would it make sense to revert > > 22c07826d77adf93ada6e17ed6ac531163dd5059 in order to fix this issue? > > Sure, can you test that after reverting bug 165228 does not reappear? > If that's the case, go ahead with reverting it. Hi Samuel, If I revert it, then bug 165228 reappears... the question is, what should be the expected behaviour? Reading the comment in this bug and in bug 165228, and also considering that 22c07826d77adf93ada6e17ed6ac531163dd5059 was reverted in previous releases branches, I'm in behaviour of reverting it in master and libreoffice-25-8 so it's not breaking the users' workflow for the time being
*** Bug 168280 has been marked as a duplicate of this bug. ***
(In reply to Xisco Faulí from comment #25) > If I revert it, then bug 165228 reappears... the question is, what should be > the expected behaviour? Reading the comment in this bug and in bug 165228, > and also considering that 22c07826d77adf93ada6e17ed6ac531163dd5059 was > reverted in previous releases branches, I'm in behaviour of reverting it in > master and libreoffice-25-8 so it's not breaking the users' workflow for the > time being In my comment #4 above I tried to sum up and clearly describe what the expected behaviour is in my opinion. Correct me if I'm wrong, or try to make LO behave like that.
(In reply to BogdanB from comment #26) > *** Bug 168280 has been marked as a duplicate of this bug. *** apologies for duplicating the bug report - I looked through what I could see and didn't spot the earlier report - my bad; with thanks to you and also to all the LibreOffice team cordially Richard Pratt
To avoid complicating things: Always use 'Save as' and 'Export' in the same folder as the original file. To export to a specific folder, regardless of its location, add the folder to your favourites (bookmark it) in the file chooser for quick access. I don't think anyone asked for the bug (https://bugs.documentfoundation.org/show_bug.cgi?id=165228) to be 'fixed'. Since the process for exporting to a specific folder is essentially the same, there is practically no workflow for exporting to the previous folder. Almost all users want to export to the folder containing the original file.
You could have a case, I often have, that I export many pages into the same folder, but aiso the case to export to the same folder. The Samuel ideea is excelent but not finished yet. Is just one case that is neglected.
There are 2 options available, the situation can be restored to the old working behaviour OR Samuel can improve also this exception not working. We have to wait some days to be solved.
(In reply to Amr Ibrahim from comment #29) > To avoid complicating things: > > Always use 'Save as' and 'Export' in the same folder as the original file. I think we need all three cases I mentioned above: * There are cases where the original file has no folder at all: New documents which have never been loaded or saved before. We need a reasonable default for that. * If someone explicitely selects a different folder for export, and then exports the same document in the same session again, he clearly expects subsequent exports to go to the folder selected for the previous export without selecting it again, and not to the original document's folder. Typical workflow: Export -> check result -> make corrections in document -> export again -> ...
Let's see if https://gerrit.libreoffice.org/c/core/+/190655 improves things here.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/67ea1fc544a0651e8da78531cfa3525f72c434ef tdf#167897 Fix save/export directory preselection with empty user profile It will be available in 26.2.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.
Testing the commit in master now: I reset to factory settings 25.8 installation: - I saved a new file in Pictures (it is important not to be Documents, could be default location for program and affecting testing). Now export as PDF - destination is Documents, OK. (For stored documents: * Current document directory) - Close and reopen the file, change the export to Desktop. It is ok (because I made the decision). - Do not close the file, but export again - Desktop. OK. Thanks, Samuel, solved! Just need a backporting to 25.8. Now I can move all computers from work to 25.8. The most annoying bug is gone! For 25.2 the bug is different, less annoying. Tested with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 67ea1fc544a0651e8da78531cfa3525f72c434ef CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Backport 25.8: https://gerrit.libreoffice.org/c/core/+/190665
Hi, please could someone test this specific case, in order to verify the fix is OK also for this situation: - Open or create a Writer document in folder A, export / save as in folder A, close LibreOffice - Open an already existing Writer document in folder B, modify it, save it directly with Ctrl-S (NOT "save as"), then try to export in pdf → if corrected, it should now propose folder B, and not folder A (current behavior in LO 25.8) Do you know if the issue fix will be backported in LO 25.8 branch (I guess yes regarding last comment) ? If not, on Linux Ubuntu we'll have to wait at least 5 months to get the bug solved with the regular debian packages… Thanks !
Xavier, I tested with your description (folder A and B), everything is fine now. You can download LibreOffice from the official website if you don't want to wait so much for an official Ubuntu version. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 67ea1fc544a0651e8da78531cfa3525f72c434ef CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Is it possible to fix this already in the next 25.8xx release?? I'm asking beacuse the note: "target:26.2.0" Unfortunately, the bug is too “annoying” to want to continue working with it for months.
(In reply to Samuel Mehrbrodt from comment #36) > Backport 25.8: https://gerrit.libreoffice.org/c/core/+/190665 Samuel already mentioned that it will be released soon in 25.8 version.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/b51bf2b747533f540e9fbb746096d52cea182e1e tdf#167897 Fix save/export directory preselection with empty user profile It will be available in 25.8.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.
Right clicking on an image and saving it will still use the document directory for the last opened file instead of using the directory for the current document.
*** Bug 168329 has been marked as a duplicate of this bug. ***
(In reply to David from comment #42) > Right clicking on an image and saving it will still use the document > directory for the last opened file instead of using the directory for the > current document. Can you please paste the version info from Help - About for the version you are testing with?
Calc: threaded(In reply to Buovjaga from comment #44) > Can you please paste the version info from Help - About for the version you > are testing with? Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0563d0e3581b5029cfe9476d5b5313d6322c5e08 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to David from comment #42) > Right clicking on an image and saving it will still use the document > directory for the last opened file instead of using the directory for the > current document. Hmm, but this is how it behaved even in 7.5, so I don't get your point. Just tested with oldest of Linux 7.6 bibisect repo. Steps were to first save an image from a document and then try to save an image from another doc located somewhere else. It remembered the image save location (a third location). If you're talking about a case where you would *not* first save the image, then it is just offering the My Documents location from Tools - Options - LibreOffice - Paths.
Open file1.odt. Then open file2.odt. Go back to file1.odt and right-click and save and image from it. It defaults to the directory for file2.odt instead of file1.odt. If this isn't considered to be part of this bug report then I can create a new one.
(In reply to David from comment #47) > Open file1.odt. Then open file2.odt. Go back to file1.odt and right-click > and save and image from it. It defaults to the directory for file2.odt > instead of file1.odt. If this isn't considered to be part of this bug report > then I can create a new one. I reproduce this in the oldest of 7.6 repository with a deleted user profile, so it is not related to this issue and therefore a new report should be created. To be clear, the string of reports here has been about what happens after saving while you are talking about what happens after merely opening documents and before any saving has taken place.
*** Bug 168346 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #48) > (In reply to David from comment #47) > > Open file1.odt. Then open file2.odt. Go back to file1.odt and right-click > > and save and image from it. It defaults to the directory for file2.odt > > instead of file1.odt. If this isn't considered to be part of this bug report > > then I can create a new one. > > I reproduce this in the oldest of 7.6 repository with a deleted user > profile, so it is not related to this issue and therefore a new report > should be created. To be clear, the string of reports here has been about > what happens after saving while you are talking about what happens after > merely opening documents and before any saving has taken place. Yep the logic discussed here applies only to Save as / Export. There are lots of other file open dialogs, which just save the last used path without additional logic. If you consider that a bug, please open a new bug report for discussion.
Created attachment 202921 [details] Screenshot from 25.8.2.1 save as after PDF-Export Hello, I have installed the newest release: ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Version: 25.8.2.1 (X86_64) Build ID: 345526217a4027cb1b9ab39bd7153c8c141a1d64 CPU threads: 32; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded Jumbo ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ But this "bug" is still present. I am only writing because, according to the chat history, this should have been fixed in 25.8.2xx.
(In reply to Viktor from comment #51) > Created attachment 202921 [details] > Screenshot from 25.8.2.1 save as after PDF-Export > > Hello, > > I have installed the newest release: > ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ > Version: 25.8.2.1 (X86_64) > Build ID: 345526217a4027cb1b9ab39bd7153c8c141a1d64 > CPU threads: 32; OS: Windows 11 X86_64 (build 22631); UI render: > Skia/Raster; VCL: win > Locale: de-DE (de_DE); UI: de-DE > Calc: CL threaded Jumbo > ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ > > But this "bug" is still present. > > I am only writing because, according to the chat history, this should have > been fixed in 25.8.2xx. Can you please file a new bug report with instructions to reproduce in the description (not as an image). Might be another corner case which QA needs to investigate.