Bug 78209 - BASIC: Race condition in FilePicker dialog methods, an perhaps other dialogs
Summary: BASIC: Race condition in FilePicker dialog methods, an perhaps other dialogs
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2014-05-02 22:50 UTC by Ewald Anderl
Modified: 2016-10-10 10:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

Screen shots and additional notes to reproduce problem (235.65 KB, application/vnd.oasis.opendocument.text)
2014-05-02 23:00 UTC, Ewald Anderl
Screen shots and additional notes to reproduce problem (updated) (240.28 KB, application/vnd.oasis.opendocument.text)
2014-05-20 21:59 UTC, Ewald Anderl

Note You need to log in before you can comment on or make changes to this bug.
Description Ewald Anderl 2014-05-02 22:50:33 UTC
Problem description:
There appear to be race conditions in the dialog(s). At least one was found that is reproducible on Linux (fc20) and LibreOffice 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.
3. ....

Current behavior:

In the reproduced race condition, getDisplayDirectory() returns an empty string.

Expected behavior:

getDisplayDirectory() should return exactly what setDisplayDirectory() was passed as an argument.
Operating System: All
Version: release
Comment 1 Ewald Anderl 2014-05-02 23:00:59 UTC
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.
Comment 2 Ewald Anderl 2014-05-06 13:36:34 UTC
Enhancement request referenced in comment 1 is Bugzilla 78210
Comment 3 Ewald Anderl 2014-05-20 21:59:45 UTC
Created attachment 99451 [details]
Screen shots and additional notes to reproduce problem (updated)
Comment 4 Ewald Anderl 2014-05-20 22:04:30 UTC
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.

Problem description:
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

Current behavior:
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.

Expected behavior:
With or without a wait (or code) following the call to  setDisplayDirectory(),  getDisplayDirectory() should return (“file:///tmp”).
Comment 5 Joel Madero 2015-02-25 23:07:20 UTC
I'm not seeing what you're seeing at all. Can you attach a document that has the macro in it?
Comment 6 Regina Henschel 2015-09-03 17:25:21 UTC
Please specify the operating system. The code for the system dialogs is different for each operating system and therefore "all" makes no sense here.
Comment 7 Buovjaga 2015-09-14 09:33:06 UTC
Comments 5 & 6 need answers.

Change back to UNCONFIRMED after you have provided the information.
Comment 8 Xisco Faulí 2016-09-11 14:01:12 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2016-10-10 10:51:35 UTC
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

Warm Regards,
QA Team