Created attachment 139336 [details]
Screenshot of dialog

Tested against

Version: 6.1.0.0.alpha0+
Build ID: 44e9bbc29cc37d2bac089b8f051478f62f7d5d31
CPU threads: 4; OS: Mac OS X 10.13.2; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded

Maybe related to tdf#114484 ?

(In reply to Xisco Faulí from comment #3)
> Maybe related to tdf#114484 ?

Quite possibly.

Hmm, the same problem exists also in 

Version: 6.0.1.0.0+
Build ID: ada232a67fbb3acf60b104a4916719dbdb891819
CPU threads: 4; OS: Mac OS X 10.13.2; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:libreoffice-6-0, Time: 2018-01-23_23:43:30
Locale: fr-FR (fr_FR.UTF-8); Calc: group

I can't reproduce it in

Version: 6.1.0.0.alpha0+
Build ID: c2ae5bc29b7064a599871358e6a4bb7b1dec2b85
CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; 
Locale: en-US (en_ES.UTF-8); Calc: group threaded

Nor in

Version: 6.1.0.0.alpha0+
Build ID: 0623f3a8f5d6fbc5e9b933cb034184084e8ac666
CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; 
Locale: es-ES (en_ES.UTF-8); Calc: group threaded

Do you build it locally or it's downloaded ?

Seems like an issue with the user profile having the LO internal file dialog enabled. The enabling/disabling of the internal file dialog was removed in bug 114484, but you can still see its value in Tools ▸ Options ▸ LibreOffice ▸ Advanced ▸ Expert configuration ▸ org.openoffice.Office.Common.Misc ▸ UseSystemFileDialog.

Alex please try with a fresh user profile.

(In reply to Yousuf Philips (jay) from comment #8)
> Seems like an issue with the user profile having the LO internal file dialog
> enabled. The enabling/disabling of the internal file dialog was removed in
> bug 114484, but you can still see its value in Tools ▸ Options ▸ LibreOffice
> ▸ Advanced ▸ Expert configuration ▸ org.openoffice.Office.Common.Misc ▸
> UseSystemFileDialog.
> 
> Alex please try with a fresh user profile.

Putting to NEEDINFO

OTOH, Heike, can you test it on your mac?

(In reply to Yousuf Philips (jay) from comment #8)
> Seems like an issue with the user profile having the LO internal file dialog
> enabled. The enabling/disabling of the internal file dialog was removed in
> bug 114484, but you can still see its value in Tools ▸ Options ▸ LibreOffice
> ▸ Advanced ▸ Expert configuration ▸ org.openoffice.Office.Common.Misc ▸
> UseSystemFileDialog.
> 
> Alex please try with a fresh user profile.

Hmm, my master build instdir/LO.app always uses a fresh profile and I saw the problem there first. Let me try with LODev (installed on my local disk) in SafeMode.

OK, so SafeMode with

Version: 6.1.0.0.alpha0+
Build ID: 44e9bbc29cc37d2bac089b8f051478f62f7d5d31
CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded


shows the correct Finder dialog, which means that my LO local profile has indeed been corrupted, yet I don't ever recall activating the Native Dialog switch.

@Jay : could the recent removal of the option have caused this ?

Tried with the official Vanilla version and got the inbuilt dialogs. But after cleaning the user folder everything was fine. Don't remember if I changed the configuration before.

Building master at the moment, will report later. The patch https://gerrit.libreoffice.org/#/c/46546/ (bug 114484) just hides access to the checkbox at the UI.

In my own master build

Version: 6.1.0.0.alpha0+
Build ID: 44e9bbc29cc37d2bac089b8f051478f62f7d5d31
CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded

In the advanced configuration settings :
UseSystemFileDialog is set to False.

Resetting to True, saving and restarting my LODev build shows the native Finder dialog again with FileOpen (so at least that works correctly).

I use my own LODev builds 99% of the time. Every once in a while, I might test a bug against a LODev from the TDF download. It is possible therefore that one of these builds corrupted my LODev user profile.

Note that I also have LOVanilla. If the problem is apparent there, as Heiko has indicated, then this would then also affect my usual LO user profile (sigh).

@Heiko : I'm beginning to suspect corruption of the user profile caused by LOVanilla...

I reset the flag with LibreOffice 5442. My native Finder dialog is now displayed correctly in that version and the LOVanilla version. The question still remains as to how the flag got set from True to False.

Tested with master from today, make clean && make build-nocheck = native file dialogs. Will report at ESC that Vanilla might have issues.

Those who claim to have seen this with LibreOffice Vanilla from the Mac App Store, are you sure that you have been able to reproduce with a fresh profile? Note that the profile directory for LibreOffice Vanilla is "~/Library/Containers/com.collabora.libreoffice-free/Data/Library/Application Support/LibreOfficeVanilla"

In fact, I would be a bit surprised if the LO's own file picker even works in a sandboxed process like LibreOffice Vanilla. Ideally the option and the code should be removed altogether from a sandboxed macOS build.

After all, the very point of sandboxing is that the process's own code (include the own "file picker") is not be allowed to even look at random locations in the file system. The system file open/save dialog uses a separate process outside the sandbox as a helper to do it, and the sandboxed process communicates with that helper. See https://developer.apple.com/library/content/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17 for instance.

Why has this been set to resolved notourbug ?

(In reply to Tor Lillqvist from comment #18)


> After all, the very point of sandboxing is that the process's own code
> (include the own "file picker") is not be allowed to even look at random
> locations in the file system. The system file open/save dialog uses a
> separate process outside the sandbox as a helper to do it, and the sandboxed
> process communicates with that helper. See
> https://developer.apple.com/library/content/documentation/Security/
> Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//
> apple_ref/doc/uid/TP40011183-CH3-SW17 for instance.

I didn't know that LOVanilla set a user profile elsewhere than the usual folder, so that would be my mistake for assuming that. I couldn't immediately see where the change might have come from (and still can't), and that was the only most recent change to my LO app surroundings that I had.

Setting to NOTOURBUG implies that it is some other (upstream) software's problem, or did someone set because LOVanilla was mentioned ? If that is the case, then I would posit that that is the wrong setting, as LOVanilla is supported on our bugtracker, or have things changed again recently and are we no longer following it.

So, either we support LOVanilla here, in which case NOTOURBUG is incorrect, or else someone has come up with another reason for setting that flag and not explained it ? Call me dumb, but I'd like to understand.

(In reply to Tor Lillqvist from comment #17)
> ...are you sure that you have been able to reproduce with a fresh
> profile?

See my comment 12 and 16. 

Vanilla is kindly provided by Collabora but isn't an official TDF app. If the issue is caused by the packaging the right solution is NOB, that was my take on it. Up to QA how to deal with it.

Hi Alex,
(In reply to Tor Lillqvist from comment #17)
> Those who claim to have seen this with LibreOffice Vanilla from the Mac App
> Store, are you sure that you have been able to reproduce with a fresh
> profile? Note that the profile directory for LibreOffice Vanilla is
> "~/Library/Containers/com.collabora.libreoffice-free/Data/Library/
> Application Support/LibreOfficeVanilla"

Hi Alex,
Did you try to clean the profile in the path provided by Tor ?

OK, so for whatever reason, I can't reproduce this any more.

Closing as WFM