Bug 92191 - clicking an open document file in Finder opens LibO but not the document
Summary: clicking an open document file in Finder opens LibO but not the document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.4.4.2 rc
Hardware: x86-64 (AMD64) macOS (All)
: highest critical
Assignee: Andras Timar
URL:
Whiteboard: target:5.2.0
Keywords:
: 92364 92462 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-06-19 18:04 UTC by MJHauan
Modified: 2016-10-25 19:08 UTC (History)
7 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 MJHauan 2015-06-19 18:04:26 UTC
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
Comment 1 Alex Thurgood 2015-06-22 07:53:50 UTC
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
Comment 2 Alex Thurgood 2015-06-25 10:05:26 UTC
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.
Comment 3 Alex Thurgood 2015-06-25 10:06:39 UTC
(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.
Comment 4 Andras Timar 2015-06-25 18:46:51 UTC
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.
Comment 5 MJHauan 2015-06-25 19:08:30 UTC
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.
Comment 6 tommy27 2015-06-27 05:32:55 UTC
*** Bug 92364 has been marked as a duplicate of this bug. ***
Comment 7 tommy27 2015-06-27 05:36:06 UTC
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?
Comment 8 Andras Timar 2015-06-27 07:35:30 UTC
(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.
Comment 9 Andras Timar 2015-06-27 19:22:24 UTC
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
Comment 10 Andras Timar 2015-06-29 07:28:24 UTC
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
Comment 11 Alex Thurgood 2015-07-01 07:16:31 UTC
*** Bug 92462 has been marked as a duplicate of this bug. ***
Comment 12 Tor Lillqvist 2015-07-01 07:22:35 UTC
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
Comment 13 symcx 2015-07-06 16:21:20 UTC
it’s the vanilla-verion of collabora produxtivity ltd. you get via teh apple app store.
Comment 14 Andras Timar 2015-07-06 16:56:28 UTC
(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.
Comment 15 Commit Notification 2016-03-04 10:34:42 UTC
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.