Selecting an ODF file in Finder opens LibreOffice but not the selected file. LibreOffice Vanilla is set as the default app for the selected files. LibreOffice: Version: 4.4.4.2 Build ID: 323549d66ffd3888c6a5058f7f6c9f0a279e0d3f Locale: en.UTF-8 MacBook Pro Model Identifier: MacBookPro11,3 Processor Name: Intel Core i7 Processor Speed: 2.5 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB Boot ROM Version: MBP112.0138.B14 SMC Version (system): 2.19f12 System Version: OS X 10.10.3 (14D136) Kernel Version: Darwin 14.3.0 Boot Volume: Macintosh HD Boot Mode: Normal
Works fine on Version: 5.1.0.0.alpha1+ Build ID: 843f7335b2e11dde66d5f6e0f98b98e30eff7119 Locale : fr-FR (fr.UTF-8) OSX 10.10.3, so this is a problem specific to the Collabora product
Tested on Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale : fr_ Can confirm problem, so not specific to Collabora build, and solved in current master. If 4.3.x is to see further releases, would be good to be able to backport, but without knowing which commit fixed it, will be difficult. Closing as WFM because it works in master.
(In reply to Alex Thurgood from comment #2) > Tested on > > Version: 4.4.3.2 > Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 > Locale : fr_ > > current master. If 4.3.x is to see further releases, would be good to be Sorry, I meant backport to 4.4.x of course.
TDF LibreOffice always works fine for me. I tested 4.4.3.2 on OS X 10.9.5 and on OS X 10.10.3. This is what users report in general, so I accept it as truth. On the other hand, the App Store version does not for for people. Someone reported a line from Console log: 22.06.15 19:25:14,270 CoreServicesUIAgent[53491]: Error -60005 creating authorization I also saw this line once under OS X 10.10.3, but not always. So this can be unrelated. Most of the times nothing is written into the log, and opening file from Finder fails silently. It can be related to sandboxing or to the fancy app name "LibreOffice Vanilla". I can imagine that it would have worked with plain "LibreOffice". Any ideas are welcome.
I installed the latest development version Version: 5.1.0.0.alpha1+ Build ID: 0e2db2dd3413d760afaa4cfab4c7c224222b949a TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-06-25_06:30:25 Locale: en-US (en.UTF-8) and, contrary to the behavior of the Vanilla version, clicking a file in Finder properly starts the program and loads the selected document.
*** Bug 92364 has been marked as a duplicate of this bug. ***
has anyone tested the 5.0 RC1 to see if the issue is fixed in the 5.0.x codeline just as in the 5.1.x branch?
(In reply to tommy27 from comment #7) > has anyone tested the 5.0 RC1 to see if the issue is fixed in the 5.0.x > codeline just as in the 5.1.x branch? This bug occurs only for the App Store version.
It seems to a sandboxing problem, because I changed the name of the bundle back to LibreOffice and rebuilt the package, and it didn't help. When I tested LOfC 4.3, I saw this line in the log: lsboxd[224]: Denied process 770(UNKNOWN) access to shared list com.collabora.libreoffice.LSSharedFileList
dbgutil build of LibreOffice Vanilla: Andrass-Mac-mini:lof-4.4 timar$ LibreOffice\ Vanilla.app/Contents/MacOS/soffice ~/Documents/4.1.0.odt warn:desktop.app:8085:1:desktop/source/app/app.cxx:235: cannot open /user/extensions/buildid for reading: 21 warn:desktop.app:8085:1:unotools/source/ucbhelper/localfilehelper.cxx:205: cannot open directory /user/extensions: 21 warn:desktop.app:8085:1:desktop/source/app/app.cxx:246: cannot remove file /registry/com.sun.star.comp.deployment.component.PackageRegistryBackend/unorc: 21 warn:desktop.app:8085:1:desktop/source/app/app.cxx:250: cannot create path /user/extensions: 21 warn:desktop.app:8085:1:desktop/source/app/app.cxx:254: cannot open /user/extensions/buildid for writing: 21 warn:desktop.app:8085:1:desktop/source/app/langselect.cxx:125: ignoring Exception "component context fails to supply service 'com.sun.star.configuration.ReadOnlyAccess' of type 'com.sun.star.container.XHierarchicalNameAccess'" warn:tools.rc:8085:1:tools/source/rc/resmgr.cxx:213: opening dir /Resources/resource/ failed warn:vcl.app:8085:1:vcl/source/app/IconThemeScanner.cxx:30: Could not determine status for file '/Resources/config/'. libc++abi.dylib: terminating with uncaught exception of type com::sun::star::uno::DeploymentException Abort trap: 6
*** Bug 92462 has been marked as a duplicate of this bug. ***
Fixed now in the relevant branches, new builds will be produced and submitted for review soonish. commit 9d930ddacb402f02642a1d0119d258646bf0d7fd Author: Tor Lillqvist <tml@collabora.com> Date: Tue Jun 30 19:42:45 2015 +0300 tdf#92191: Don't use any IPC pipe in a sandboxed OS X app Creating the pipe fails when sandboxed. This caused us to not start the OfficeIPCThread, and that then meant that the file open requests coming in through VCL_NSApplication's application:openFile: method in vclnsapp.mm were not processed properly. The OS takes care of not starting multiple LO apps simultaneously anyway, so we don't really need any pipe, I hope. Change-Id: Ia920520ce2928787313f83199028f9c9942f61f3
it’s the vanilla-verion of collabora produxtivity ltd. you get via teh apple app store.
(In reply to symcx from comment #13) > it’s the vanilla-verion of collabora produxtivity ltd. you get via teh apple > app store. FYI, next release, which is waiting for review in App Store, have this issue fixed.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2bcef51421963677daed826d6ea4be19ecdc174b tdf#92191: Don't use any IPC pipe in a sandboxed OS X app It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.