Bug 129886 - Save Untitled document uses Path set in Options rather than "last-used" directory
Summary: Save Untitled document uses Path set in Options rather than "last-used" direc...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.0.1 rc
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 133674 (view as bug list)
Depends on: 43021
Blocks: Save
  Show dependency treegraph
 
Reported: 2020-01-08 13:57 UTC by sdc.blanco
Modified: 2020-07-30 02:15 UTC (History)
5 users (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 sdc.blanco 2020-01-08 13:57:41 UTC
1. New Document.
2. Save (but not in the Directory named in Options>LibreOffice>Paths>MyDocuments)
3. Second New Document.
4. Save.

Actual Result:  opens directory specified in Paths-My Documents
Expected Result:  opens directory where first document was saved.

Actual result obtained in:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 
Locale: da-DK (en_DK); UI-Language: en-US
Calc: threaded
(7 jan 2020 build)

Expected result obtained in:

Version: 6.3.4.2 (x64)
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: de-DE (en_DK); UI-Language: en-US
Calc: threaded

Uncertain if this change was intentional. Cf bug #96503 and bug #129292
Comment 1 Oliver Brinzing 2020-01-08 17:57:48 UTC
also reproducible with

Version: 6.4.0.1 (x64)
Build-ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc

saving a new document always preselects workdir.
Comment 2 Timur 2020-01-09 11:44:54 UTC Comment hidden (obsolete)
Comment 3 sdc.blanco 2020-01-09 13:02:01 UTC
(In reply to Timur from comment #2)
> I see this as a duplicate of #129292,  just with opposite request. 
> Please close and write there.
This report (bug 129886) is to note a bug in the intended action. It appears in 6.4.0.1rc and forward (but not in 6.3.x).  In effect, a regression. (Bug 129291 was classified as a "documentation" problem, not an enhancement.)
Comment 4 sdc.blanco 2020-01-11 16:41:50 UTC
(In reply to Oliver Brinzing from comment #1)
> also reproducible with
> 
> Version: 6.4.0.1 (x64)

Does it work (as expected) for you with 6.3.x?  Maybe we should mark this as possibleRegression and bibisectrequest?
Comment 5 Oliver Brinzing 2020-01-12 07:38:23 UTC
(In reply to sdc.blanco from comment #4)

> Does it work (as expected) for you with 6.3.x?  Maybe we should mark this as
> possibleRegression and bibisectrequest?

The new behaviour was intended, please have a look at:

Bug 43021 - Macros: FilePicker method setDisplayDirectory shows wrong folder with native dialog Win 7 (64-bit)

Until LO 6.3.4 it was necessary to use a workaround via "WorkPathChanged" to force
the windows filepickter to show a directory, e.g.:

https://bugs.documentfoundation.org/show_bug.cgi?id=43021#c50

[...]
oRegistryKeyContent.WorkPathChanged = true
oRegistryKeyContent.commitChanges
[...]
oFilePickerDlg.setDisplayDirectory(ConvertToURL("C:\test\"))
Comment 6 sdc.blanco 2020-01-12 09:43:04 UTC
(In reply to Oliver Brinzing from comment #5)
> The new behaviour was intended, please have a look at:
I am still uncertain.
 
> Bug 43021 - Macros: FilePicker method setDisplayDirectory shows wrong folder
> with native dialog Win 7 (64-bit)
Good detective work on your part, but isn't that bug supposed to be about Macros (and how the Basic commands work)? (that is how it is classified).

Meanwhile, I can understand that this is where/how the new behavior was introduced, but maybe it was an "accident" in the sense that the repair of the macros has also spilled over into the "standard" behavior?
Comment 7 Mike Kaganski 2020-03-02 07:00:14 UTC
(In reply to sdc.blanco from comment #6)
> Good detective work on your part, but isn't that bug supposed to be about
> Macros (and how the Basic commands work)? (that is how it is classified).
> 
> Meanwhile, I can understand that this is where/how the new behavior was
> introduced, but maybe it was an "accident" in the sense that the repair of
> the macros has also spilled over into the "standard" behavior?

While bug 43021 was about macros, related bug 34303 wasn't; and in fact, the change has the intended result that management of initial directories in File dialogs has been made consistent over platforms and managed by LibreOffice (while previously, it was managed by system on Windows).

So any "regression" aspect of this report should be removed, and if some change in behaviour is wanted, it should be suggested, discussed and implemented as a general change, unrelated to previous state. It should take different kind of dialogs (open/save/export/direct export/macro; different modules) into account; if, why and how should they behave differently on different OSes, etc.
Comment 8 bugzilla2 2020-06-07 10:21:49 UTC
ok, so fixing a bug in macros that affects maybe 3% of the users breaks the workflow for all LibO windows users ... I doubt that this is well balanced ;)

Regarding the "regression" vs. "enhancement" topic: from a user perspective, its definitely a regression, because it simply worked up until 6.3 and doesn't work anymore in 6.4. It doesn't matter if the old behavior was "unintentional", it was the old behavior and it had its advantages.

To make it short: I also would love to have an option to choose between "Use last saved Dir" and "use default-dir". I think this can be achieved without breaking the macros again, even thou it is really an enhancement then, that requiriere some new code. Maybe we can undo the commit that fixes the macro-bug until this new code is available? I doubt that this new function will be introduced in a feature-frozen 6.4 series...
Comment 9 bugzilla2 2020-06-07 10:24:18 UTC
*** Bug 133674 has been marked as a duplicate of this bug. ***
Comment 10 bugzilla2 2020-06-27 10:00:12 UTC
Bug/Regression still exists in 7.0 Beta 2...