Bug 63622 - FILEOPEN: "Import / open files" forgets the last folder used
Summary: FILEOPEN: "Import / open files" forgets the last folder used
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Don't use this account, use tml@iki.fi
URL:
Whiteboard: BSA target:4.1.0 target:4.0.4
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-04-17 07:04 UTC by Carsten Rohr
Modified: 2013-07-10 22:18 UTC (History)
1 user (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 Carsten Rohr 2013-04-17 07:04:13 UTC
Problem description:

LibreOffice forgets the folder which was used at last.


Steps to reproduce:

When importing a picture out of a file from my hard drive I have to navigat to a certain folder and then click on the file to open/import the picture into my write document. If I have to import a second picture-file out of the samte folder LibreOffice has forgotten the folder I used at last and I have to navigate to it again. This is very anoying, if you have to import 50 pictures or more.
I think this problem of "forgetting the last used folder" is found at different other situations in LibreOffice but I cannont confirm this right now.1. ....

Current behavior:

Expected behavior:
Like in LibreOffice 3.x LibreOffice should show the folder, which was used at last, when "import picture from file", "oben file", "import something", etc requests are started

              
Operating System: Windows 7
Version: 4.0.2.2 release
Last worked in: 3.6.6.2 rc
Comment 1 Michael Stahl (CIB) 2013-04-25 21:08:39 UTC
confirmed, "File->Open" and "Insert->Picture->From File" do not
remember the last used directory.

(these settings are stored as "FilePicker_Save" and "FilePicker_Graph"
in the configuration)

regression in VistaFilePicker, introduced by:

commit 56d41fef8f96888d5aaf39a9c4d0c7eca5b63d44
Author: Tor Lillqvist <tlillqvist@suse.com>
Date:   Tue Jan 22 13:01:44 2013 +0200

    "Fix" bnc#777788
Comment 2 Michael Stahl (CIB) 2013-04-25 21:18:47 UTC
just for the record on Windows 7 both default locations of
File->Open (Documents) and Insert->Picture (gallery)
are available with 1 click on the pane on the left of the picker
so no need to show these by default.
Comment 3 Don't use this account, use tml@iki.fi 2013-04-25 21:24:07 UTC
Copying some (hardly "secret") information from the non-public SUSE bug report bnc#777788:


Platform: Windows 7
Build:    SUSE Libreoffice 3.5

Steps
-----

    1. Specify a document to export to C:\path\test.pdf.

    2. Open another file in C:\other\path\test.odt,

    3. Select from the menu File->Export PDF...

Problem
-------

    * The default path of exporting dialog is always set to C:\path. It is
      expected that the default path is as same as the opened document to be
      exported.      

Extra Info
----------

    * This is a Windows specific problem, also losing consistence with how
      Libreoffice behaves correctly in SLED.

===

Still reproduce in SUSE Libreoffice 3.6 RC2 windows version, also in "menu
File->Export".

If you just open the Export window, not save the PDF file, the directory is
same with the file. if you saved the PDF file, the directory will remain to the
saved directory always.

===

But is the behaviour consistent with how other Windows applications behave? (I
don't know, it's an honest question.) We should in general try to be consistent
with the platform, not with (the same application on) some other platform,
surely?

Anyway, debugging this now, hopefully will be able to come up with a fix
soonish.

===

Hmm, it is harder than expected to reproduce this exactly. At first I tbought I
saw it, but now then not again;) Is it so that it happens only on Windows 7
(and Vista, most likely)? I am debugging on XP.

===

Reading
http://msdn.microsoft.com/en-us/library/windows/desktop/bb761828(v=vs.85).aspx
, it says:

"In general, we do not recommended the use of this method. If you call
SetFolder before you display the dialog box, the most recent location that the
user saved to or opened from is not shown. Unless there is a very specific
reason for this behavior, it is not a good or expected user experience and
should therefore be avoided. In almost all instances,
IFileDialog::SetDefaultFolder is the better method."

(And indeed, that is what the code in the "VistaFilePicker" does, it does not
call SetFolder() but SetDefaultFolder().)

So is Microsoft's recommendation that there should be just one
per-application-instance most-recent-location to open or save/export files
from? Do we want to go against that recommendation? I *think* that as such that
would be trivial to do in the code (will have to verify).

===

BTW, would the customer want this default to change also for File:Save As and
File:Open? They too use the same single most-recent-location default, don't
they? (Yeah, I need to check myself.) Is it imperative that any behaviour
change affects only the File:Export PDF default folder and nothing else?

(And finally, of course, one wonders if it wouldn't be a regression to change
this in general for everybody, so should the change be an option that this one
customer then can turn on?)

===

Why the File:Export dialog has a different default location than the
File:Export PDF... is a mystery to me, though. As far as I can see in the
debugger, they go through the exact same code path, and do the same calls to
the Windows (Vista and later) file selection dialog API.

===

And after that the "fix" (quotes mine, I was not at all sure about it) was committed to the suse-3.6 branch, and later cherry-picked to master and libreoffice-4.0 too.
Comment 4 Commit Notification 2013-04-26 05:50:41 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b032a3ef1aeb520fe9b9e6a65dc4fcedff13f2b

fdo#63622: Revert '"Fix" bnc#777788'



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2013-04-26 06:11:38 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ddbe7cd615689797ef8029c29a8eaeafd610ad09&h=libreoffice-4-0

fdo#63622: Revert '"Fix" bnc#777788'


It will be available in LibreOffice 4.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 6 Michael Stahl (CIB) 2013-07-10 22:18:37 UTC
import and file open working again here anyway.