There appear to be race conditions in the dialog(s). At least one was found that is reproducible on Linux (fc20) and LibreOffice 184.108.40.206 version. The race condition was only reproduced on Linux using the FilePicker dialog using the System style dialog. Note, that it is possible that the same underlying issue is present with the System dialog on Windows, but that it is masked by the behavior associated with Bug 43021 where an empty string is always returned by getDisplayDirectory().
Steps to reproduce:
1. Write and run code with the getDisplayDirectory() method immediatly following setDisplayDirectory()
2. Single step or insert a 50 ms wait, getDisplayDirectory() returns the correct result.
In the reproduced race condition, getDisplayDirectory() returns an empty string.
getDisplayDirectory() should return exactly what setDisplayDirectory() was passed as an argument.
Operating System: All
Version: 220.127.116.11 release
Created attachment 98353 [details]
Screen shots and additional notes to reproduce problem
This bug was discovered while documenting a requested enhancement for the behavior of FilePicker and FolderPicker dialog(s). This is the current version of that document and should provide some context. It includes the code where the problem appeared as well as additional discussions and screen shots from the IDE showing the problem in my environment.
The enhancement request will be filed seperately. I will come back here to provide a bugzilla reference once it is filed.
Enhancement request referenced in comment 1 is Bugzilla 78210
Created attachment 99451 [details]
Screen shots and additional notes to reproduce problem (updated)
I was request to provide a simple reproducable test case as an exampe for a related problem. I have proactively done the same for this bug report. I have also updated the associated document which was streamlined.
After making a call to setDisplayDirectory(), the call to getDisplayDirectory() should return the new directory value. If the “get...” call is made too quickly, the correct value is not returned. It is possible that other similar race conditions exist. Given the behavior, it is possible that this is also related to bug 43021.
How to reproduce the problem:
1. In LibreOffice, open Tools --> Options; in the LibreOffice – General tab ensure that “Use LibreOffice dialogs” is unchecked.
2. In LibreOffice, open Tools --> Macros --> Organize Macros --> pick any module to edit
3. Type (or cut/paste) the following program in to the empty “Sub” of your choice (Main will do):
Dim oDialog 'FilePicker dialog
Dim vBefore 'value before call to setDisplayDirectory
Dim vAfter 'value after call.
Dim s 'tmp string for creatint output
oDialog = CreateUnoService("com.sun.star.ui.dialogs.FilePicker")
Print "setDisplayDirectory --> /tmp" 'pick any reasonable directory.
vBefore = oDialog.getDisplayDirectory() 'Before
REM Wait 500 'This line makes it work
vAfter = oDialog.getDisplayDirectory() 'After
s = s & "getDisplayDirectory before = [" & vBefore & "] " & Chr$(10)
s = s & "getDisplayDirectory after = [" & vAfter & "] " & Chr$(10)
MsgBox s, 0
4. Run this Macro, getDisplayDirectory() fails
5. Edit the Macro to remove the 'REM' in front of the 'Wait” statement
6. Run the Macro again, getDisplayDirectory() works correctly
Without the “Wait” statement, getDisplayDirectory() returns an empty string. With the “Wait” statement, getDisplayDirectory() returns the correct directory (“file:///tmp”).
Using the Libreoffice dialog style appears to work correctly.
With or without a wait (or code) following the call to setDisplayDirectory(), getDisplayDirectory() should return (“file:///tmp”).
I'm not seeing what you're seeing at all. Can you attach a document that has the macro in it?
Please specify the operating system. The code for the system dialogs is different for each operating system and therefore "all" makes no sense here.
Comments 5 & 6 need answers.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INVALID
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Sun, 11 Sep 2016 12:29:16 +0200
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker