Bug 37593 - "File > New > Template" no longer remembers my last open folder
Summary: "File > New > Template" no longer remembers my last open folder
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
3.4.0 release
Hardware: All All
: medium normal
Assignee: Stephan Bergmann
Whiteboard: bibisected35 bibisected35older target...
Keywords: regression
: 38009 46194 47504 47651 (view as bug list)
Depends on:
Reported: 2011-05-25 09:29 UTC by Frédéric Buclin
Modified: 2012-04-05 07:53 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Buclin 2011-05-25 09:29:40 UTC
Till 3.3.2, LibO opened my "Mes modèles" folder containing my own templates when selecting "File > New > Template". In 3.4rc1, it keeps leaving this folder and displaying its parent folder. This is a regression as it forces me to reopen my "Mes modèles" folder again and again. It should remember where I use to look for my templates, as it did in older releases.
Comment 1 Guilherme 2011-05-26 08:40:21 UTC
(In reply to comment #0)

In my company, we prefer to have this new behavior of restoring the template parent folder, because we have some template folders and is important to us to open the templates on the parent default folder.

So, I suggest that this issue should be an option in LO preferences rather than return to the previous functionality.
Comment 2 vitriol 2011-06-06 15:06:00 UTC
*** Bug 38009 has been marked as a duplicate of this bug. ***
Comment 3 Mark Nienberg 2011-10-18 19:05:30 UTC
This problem still exists in 3.4.3.

The description in Bug 38009 is more complete. 

If it is decided to make this an option to either open the last folder or open the parent folder, then it should just do one or the other. Currently it opens the last folder, then delays a bit, then switches to the parent folder. During the delay, you cannot select a template in the last folder even though you can see templates listed.
Comment 4 David C. Rankin 2011-10-20 08:13:48 UTC
Devs, is there any progress on this bug?  I can confirm it is still present in 3.4.3-4 (Arch Linux). I don't know how much trouble this one is to fix, but I can relate that it is one of the top frustrations in Libre Office right now.

For users like myself that have multiple templates for letterhead, etc., having to watch my templates disappear right in front of my eyes when LO magically jumps from the 'My Templates' directory (last used) up to the parent folder under File -> New -> Templates and Documents is frustrating. This happens with every letter I have to write.

I know manpower is always stretched, but if this one could be bumped up a bit in priority, it would get rid of one of the most visible bugs introduced in 3.4 (or late 3.3). It doesn't seem that difficult to just tell LO to stay with the 'last used' template directory. It has done that for years before this got introduced.

From a rational standpoint, I don't know of anyone that uses any of the canned templates provided in LO (or any other office suite for that matter). The only templates a majority of users ever use are those they have created which get stored under 'Templates and Documents' -> 'My Templates' in LO. That, in my experience, has always been where OO/LO returned to when the user selects File -> New -> Templates and Documents prior to this bug.

Thanks for any help you can give to this bug -- it's one I'm reminded of every single day.
Comment 5 Mark Nienberg 2011-10-20 14:53:26 UTC
Just to be clear though, the problem can easily be demonstrated using just the few templates provided with the standard install. This is not an issue with custom folders. For example, start a presentation using one of the templates in the Presentation Backgrounds folder. Then try to make another new document from any template.  The Presentation Backgrounds folder will initially be open, but the templates in it will not be selectable. After a few moments of inactivity, the dialog will jump up to the parent folder.
Comment 6 manj_k 2011-11-08 11:05:14 UTC
Please don't change the LibO version, see
→ http://wiki.documentfoundation.org/BugReport_Details#Version
Comment 7 Björn Michaelsen 2011-12-23 12:01:52 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 8 Cor Nouws 2011-12-31 08:49:14 UTC
thanks for posting this issue - didn't put energy in it myself, but each time starting from a template takes about four additional key strokes ..
Comment 9 Cor Nouws 2012-02-15 07:54:31 UTC
Hi Joseph,

Sorry my C++ is not so good. Therefore could you pls have a look at this commit:
It could be related to this bug?
Thanks! - Cor
Comment 10 Stephan Bergmann 2012-02-15 12:48:44 UTC
The relevant code looks overly complicated.

Removing *two* entries off the end of pHistoryList in SvtTemplateWindow::OpenHistory (svtools/source/contnr/templwin.cxx) indeed looks odd, but is effectively in there "since the beginning" (subsequent commits just changed the underlying data structures).

What apparently happens if you follow the steps described in bug 38009 and you reopen the dialog after you had selected a template from "My Templates" the last time it had been opened, is

- a call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US URL

- followed by a call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US/My%20Templates URL

- followed by a call to ClearHistory -- this apparently comes from UpdateHdl_Impl, no idea what it is supposed to do

- followed by another call to SvtTemplateWindow::AppendHistoryURL with the .../templates/en-US URL

and in particular no calls to OpenHistory involved (which might therefore be a red herring after all)

That code apparently needs further investigation...
Comment 11 Cor Nouws 2012-02-15 13:02:19 UTC
@stephan: thanks for looking in this. I was so naive to think that the commit in that area ... but indeed, might be some underlying problem.
Would it be of some / little help maybe if I find out what happens with writing data to /reading from the user config files, both in 3.3 and 3.4 version?
Comment 12 Cor Nouws 2012-02-21 15:42:04 UTC
*** Bug 46194 has been marked as a duplicate of this bug. ***
Comment 13 peter Roots 2012-02-29 12:35:57 UTC
just to confirm, still present in LO3.5
Comment 14 Cor Nouws 2012-03-13 04:40:06 UTC
some testing makes clear that the value of the last open template folder is correctly written to the registrymodification.xcu:
  <item oor:path="/org.openoffice.Office.Views/Dialogs"><node oor:name="NewFromTemplate" oor:op="replace"><node oor:name="UserData"><prop oor:name="LastFolder" oor:op="fuse" oor:type="xs:string">

also it is read from that file, when initiating the dialog

one can also see, that when the dialog is open, for a short time the last open folder is active ... but that state is reverted.

Now only find where and why :-)
Comment 15 Stephan Bergmann 2012-03-13 05:12:22 UTC
Cor, sorry for not responding to your earlier comment 11.  As I said in comment 10, the code looks strange (but old and mostly unmodified), the flicker from right dir to wrong one apparently happens due to timer-triggered UpdateHdl_Impl.  Am planning on looking some more into this (already refactored the code lightly).
Comment 16 Not Assigned 2012-03-16 07:07:39 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":


fdo#37593 Make sure needsUpdate compares canonicalized paths
Comment 17 Stephan Bergmann 2012-03-16 07:30:04 UTC
Turns out jumping from the last opened directory to the template root directory shortly after opening the dialog is "by design," but should only happen in those (rare) cases where there were interim changes to the template set, invalidating the cached data.  However, comparing the current state of the template set with the cached data in user/store/.templdir.cache did not take non-canonical pathnames (containing ".." segments) into account, so always considered there were changes, always updated the cache, and so always jumped back to the template root directory shortly after opening the dialog.

Intending the fix to be included in libreoffice-3-5 (towards LO 3.5.2), too.
Comment 18 Not Assigned 2012-03-19 03:49:44 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":


fdo#37593 Make sure needsUpdate compares canonicalized paths

It will be available in LibreOffice 3.5.2.
Comment 19 Stephan Bergmann 2012-03-19 05:50:53 UTC
*** Bug 47504 has been marked as a duplicate of this bug. ***
Comment 20 manj_k 2012-03-19 17:42:47 UTC
Verified (on WinXP 32b) with
LOdev 3.5.2rc0+ 
Build ID: ec752de-73cb0b8-f269e46

OK, thanks. :)
Comment 21 manj_k 2012-03-21 07:36:31 UTC
*** Bug 47651 has been marked as a duplicate of this bug. ***
Comment 22 Cor Nouws 2012-03-21 07:54:21 UTC
works fine again in daily build. Thanks Stephan!
Comment 23 Rainer Bielefeld Retired 2012-04-05 07:53:16 UTC
I added Fix submitter as assignee because this will ease queries and bug tracking.