Description: PDF export doesn't remember last used location Steps to Reproduce: 1. Create a new document. Type something into it and save it. Say Document folder 2. File Reload 3. Click PDF export icon and save the the PDF to desktop 4. Make an edit to document 5. PDF export again.. (points to My Documents") Actual Results: Points to dir with (in this case) the ODT Expected Results: Last used export location being used Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ca657b98e49eb2282775f7919827062a7a0b4bfe CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Well this never worked perfectly, but it seems to be more broken today 1. Create a new document. Type something into it and save it. Say Document folder 2. File Reload 3. Click PDF export icon.. Select desktop & create a folder on the desktop. hit export 4. Make an edit to document 5. PDF export again.. (points to My Documents) Also found in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL point to last used directory in Version: 6.4.0.0.alpha0+ (x64) Build ID: c56bf1479cc71d1a2b0639f6383e90c1f7e3655b CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Bibisected with Windows 7.0 repo to https://git.libreoffice.org/core/commit/ffa636ba74b04b3258ec9a696bc4eac33581fa24 tdf#43021 WIN opt-out of OS recent folder usage Samuel: seeing that you did https://git.libreoffice.org/core/commit/d157c1bd70d630a58db33910d550bb8dee9fe62e tdf#126665 Remember last used file picker directory do you have an idea about this?
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to Buovjaga from comment #2) > Bibisected with Windows 7.0 repo to > https://git.libreoffice.org/core/commit/ > ffa636ba74b04b3258ec9a696bc4eac33581fa24 > tdf#43021 WIN opt-out of OS recent folder usage > > Samuel: seeing that you did > https://git.libreoffice.org/core/commit/ > d157c1bd70d630a58db33910d550bb8dee9fe62e > tdf#126665 Remember last used file picker directory > > do you have an idea about this? This issue should have been fixed with that commit.
(In reply to Samuel Mehrbrodt (allotropia) from comment #4) > (In reply to Buovjaga from comment #2) > > Bibisected with Windows 7.0 repo to > > https://git.libreoffice.org/core/commit/ > > ffa636ba74b04b3258ec9a696bc4eac33581fa24 > > tdf#43021 WIN opt-out of OS recent folder usage > > > > Samuel: seeing that you did > > https://git.libreoffice.org/core/commit/ > > d157c1bd70d630a58db33910d550bb8dee9fe62e > > tdf#126665 Remember last used file picker directory > > > > do you have an idea about this? > > This issue should have been fixed with that commit. I assume the status change was an accident. Your commit is for 7.3 and comment 0 mentions 7.4 and I still repro with master. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fb8bf5f209e1bd7fd7d8ad555ec66dbf31649ee8 CPU threads: 2; OS: Windows 11 X86_64 (build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Maybe try if the commit for bug 165228 fixes this problem then.
(In reply to Samuel Mehrbrodt (allotropia) from comment #6) > Maybe try if the commit for bug 165228 fixes this problem then. Still repro. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 41ab24cecd6ad74312843f113d2faa13259cdb7d CPU threads: 2; OS: Windows 11 X86_64 (build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
my current version of LO: Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE 25.2.2-2 Calc: threaded since recent versions (I don't know exactly when it changed) pdfs are exported to the location where the last pdf was exported to. beforehand, they were always epxorted to the same location as the odt-file was placed from which it is generated. actually, I found the latter behaviour quite handy – at least from the present point of view it is annoying to have to search for the pdf which has just been created, since it is not created in the current "working directory" but where the last pdf was saved to. in short, I want to say that I prefer the behaviour that the pdf is automatically saved in the directory of the odt-file (more precise: that this directory is the one being opened in the save-to-file-dialog.)
(In reply to soffioalcuore from comment #8) > my current version of LO: > Version: 25.2.2.2 (X86_64) / LibreOffice Community > Build ID: 520(Build:2) > CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: gtk3 > Locale: de-DE (de_DE.UTF-8); UI: de-DE > 25.2.2-2 > Calc: threaded > > > since recent versions (I don't know exactly when it changed) pdfs are > exported to the location where the last pdf was exported to. beforehand, > they were always epxorted to the same location as the odt-file was placed > from which it is generated. > > actually, I found the latter behaviour quite handy – at least from the > present point of view it is annoying to have to search for the pdf which has > just been created, since it is not created in the current "working > directory" but where the last pdf was saved to. > > in short, I want to say that I prefer the behaviour that the pdf is > automatically saved in the directory of the odt-file (more precise: that > this directory is the one being opened in the save-to-file-dialog.) Have you looked at the fix for bug 165917? Btw., you set the status to ASSIGNED, which means you will work on the code, but probably it was a mistake?
(In reply to Buovjaga from comment #9) > Have you looked at the fix for bug 165917? Btw., you set the status to > ASSIGNED, which means you will work on the code, but probably it was a > mistake? Thanks Buovjaga for pointing me to bug 165917, which I haven't looked at. so, my post is probably wrong here. please excuse me! furthermore for accidentally setting the wrong status tag!
(In reply to soffioalcuore from comment #10) > (In reply to Buovjaga from comment #9) > > > Have you looked at the fix for bug 165917? Btw., you set the status to > > ASSIGNED, which means you will work on the code, but probably it was a > > mistake? > > Thanks Buovjaga for pointing me to bug 165917, which I haven't looked at. > so, my post is probably wrong here. please excuse me! furthermore for > accidentally setting the wrong status tag! Can you try with the unreleased Win-x86_64@tb77-TDF from https://dev-builds.libreoffice.org/daily/master/current.html ?
(In reply to Buovjaga from comment #11) > (In reply to soffioalcuore from comment #10) > > (In reply to Buovjaga from comment #9) > > > > > Have you looked at the fix for bug 165917? Btw., you set the status to > > > ASSIGNED, which means you will work on the code, but probably it was a > > > mistake? > > > > Thanks Buovjaga for pointing me to bug 165917, which I haven't looked at. > > so, my post is probably wrong here. please excuse me! furthermore for > > accidentally setting the wrong status tag! > > Can you try with the unreleased Win-x86_64@tb77-TDF from > https://dev-builds.libreoffice.org/daily/master/current.html ? unfortunately not, since I use linux.
(In reply to soffioalcuore from comment #12) > > Can you try with the unreleased Win-x86_64@tb77-TDF from > > https://dev-builds.libreoffice.org/daily/master/current.html ? > > unfortunately not, since I use linux. Sure you could. Nightly builds of master against 25.8 are packaged as both RPM and DEB, select appropriate for your Linux release and install in parallel. This is already corrected for the 25.8 release, appreciated if you test it to convince yourself. https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Tested in the nightly: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 887ed47fbdb05a2cbbef5722859cdd3e7900b73c CPU threads: 14; OS: Windows 10 X86_64 (build 19045); UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded now the behavior reported in comment #0 and comment #1 is no longer happening, instead I see the new behavior from bug 165917 comment 48 going.
*** Bug 166375 has been marked as a duplicate of this bug. ***