Bug 125607 - URL to folder / directory no longer working in LO 6.2.4.2 for Mac
Summary: URL to folder / directory no longer working in LO 6.2.4.2 for Mac
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 129215 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-05-31 08:21 UTC by Thomas Maeder
Modified: 2019-12-15 09:53 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Example applescripts & results (1.44 KB, text/plain)
2019-06-13 21:59 UTC, Thomas Maeder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Maeder 2019-05-31 08:21:04 UTC
Description:
IN LO 5 / Mac, URL, it wasn't possible to select a folder using the dialog, but typing a folder URL or selecting the file and then removing just the file name worked: clicking on the URL would correctly open the folder in the Finder.
In 6.2.4.2, this behaviour no longer works, giving the error, e.g. "<URL>" is not an absolute URL than can be passed to an application". File URLs still work fine.
The problem seems universal to LO, at least Calc, Writer and Impress.


Steps to Reproduce:
1. Create a new Writer or Calc document
2. Insert a new Hyperlink (cmd-K)
3. Type a path to a folder, e.g. the desktop, e.g. file:///Users/Jack/Desktop/
(Or select a file in the dialog, yielding e.g. file:///Users/Jack/Desktop/test.txt, then remove the file name)
4. Click on the URL to the folder

Actual Results:
Click on the URL to the folder -> error "<URL>" is not an absolute URL…"
(Click on URL to file: OK, no problem)

Expected Results:
In LO 5, selection of a folder with the dialog box was not possible, but folder links as described above worked (simple workaround: select a file in the target folder, then remove the filename). This no longer is the case


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
As suggested below (even if not likely to be linked with the issue), restarted in safe mode. As expected, same behaviour.
The same behaviour is also seen in safe mode irrespective of whether OpenGL is disabled or not.
Comment 1 Alex Thurgood 2019-06-03 07:58:36 UTC
COnfirming with

Version: 6.3.0.0.alpha1+
Build ID: 92b0b8d78d69bd917842b09af7888b402144baeb
CPU threads: 4; OS: Mac OS X 10.14.4; UI render: default; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded


This works correctly in LO5472
==>> regression
Comment 2 Xisco Faulí 2019-06-06 15:30:08 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=d59ec4cd1660410fa1b18c50d2d83b1417a82ddc

author	Stephan Bergmann <sbergman@redhat.com>	2019-03-29 14:01:19 +0100
committer	Stephan Bergmann <sbergman@redhat.com>	2019-04-03 12:08:14 +0200
commit	d59ec4cd1660410fa1b18c50d2d83b1417a82ddc (patch)
tree	f42ff98ea0fec775c47ac277e6e79d1ace6363ec
parent	3b41abe6933046612c445f16c3879975eed650ba (diff)
Filter out problematic file URLs

Bisected with: bibisect-mac64-6.3

Adding Cc: to Stephan Bergmann
Comment 3 Stephan Bergmann 2019-06-06 15:57:52 UTC
That commit is part of a security fix, to prevent that clicking on hyperlinks executes arbitrary applications, which may surprise the user (who assumes that clicking on a hyperlink will open the browser, and as such not execute unexpected code on their machine).  On macOS, applications are stored as directories (of a certain structure) in the file system, which is why this commit blocks opening directories (including those not representing applications, as something one could consider as "collateral damage").  As I wrote on our closed security list, "I don't think we are taking away reasonable functionality when also blocking any other sort of non-regular file".

Thomas, what is your use case of having hyperlinks to folders in documents?

One detail that was caused by this being a security fix is that the "is not an absolute URL" error message is wrong.  I can probably fix that part, even if overall I would prefer to close this bug as WONTFIX.
Comment 4 Xisco Faulí 2019-06-06 16:10:29 UTC
(In reply to Stephan Bergmann from comment #3)
> Thomas, what is your use case of having hyperlinks to folders in documents?
> 
> One detail that was caused by this being a security fix is that the "is not
> an absolute URL" error message is wrong.  I can probably fix that part, even
> if overall I would prefer to close this bug as WONTFIX.

Dear Thomas,
Please answer stephan's question. Setting to NEEDINFO for the time being.
Lowering severity
Comment 5 Thomas Maeder 2019-06-06 20:29:28 UTC
Dear Stephan, the case for having folders in hyperlinks is fundamentally the same as for targeting files. I use them a lot in general as a convenient way to point to documents.
However, if you want to target a collection of various documents on a particular topic or project, this is best done with a folder link, which will open a corresponding window in the Finder (or File Explorer on Windows / Linux). Another example: if you store documents by year (e.g. letters), you can make a formula (HYPERLINK) that will automatically open the folder for the current year. Actually, there are many possible uses of this feature...
Comment 6 Stephan Bergmann 2019-06-07 11:56:57 UTC
(In reply to Thomas Maeder from comment #5)

OK, I see your point regarding a use case.  However, I would assume that links to directories have only ever worked in a useful way by chance, due to the details of how opening hyperlinks is implemented in LO for the various platforms, and was never meant to be an "official" feature.  (Witness how "Insert - Hyperlink..." doesn't directly allow to select a directory.)

I have no good idea how to proceed here.
Comment 7 Thomas Maeder 2019-06-13 21:35:32 UTC
(In reply to Stephan Bergmann from comment #6)

I cannot judge on how LO works on other platforms, but MS Excel (which I still have to use at the office...) behaves in a similar way on both Mac and Windows: while it does not let you select a folder in all implementations, links to folders have (up to now) always worked as expected on both platforms.
As for the security issue, it seems it is possible to detect applications. Two examples using Applescript (simple folder vs application) to get their info are given below. Looking at both resulting attribute sets:
- Both applications and folders indeed  have the "folder" attribute (your concern).
- Applications names have the ".app" ending, folders don't.
- The file type of apps is "APPL", that of folders is an empty string "".
- Applications (+ others) are bundles (the "package folder" attribute), not folders.
Other attributes may be used, such as "kind", but, as seen in the example, the returned value is localised (in French in this example), making it harder to write generic code.
A safe way to differentiate seems to me to check for the "APPL" attribute. One could also possibly ban opening bundles. What do you think?

------
1) Folder: Desktop

1a) Script
set elem to "Desktop" as alias
get info for elem

1b) Result
{name:"Desktop", creation date:date "lundi, 10 décembre 2007 à 22:05:00", modification date:date "jeudi, 16 décembre 2010 à 15:22:36", size:6148, folder:true, alias:false, package folder:false, visible:true, extension hidden:false, name extension:missing value, displayed name:"Bureau", default application:alias "Hobbes:System:Library:CoreServices:Finder.app:", kind:"Dossier", folder window:{0, 0, 0, 0}, file type:"
Comment 8 Thomas Maeder 2019-06-13 21:46:34 UTC
...
file type:"
Comment 9 Thomas Maeder 2019-06-13 21:59:03 UTC
Created attachment 152176 [details]
Example applescripts & results

...Please see the attached file, as I experienced some formatting problems copying to the commend area.
Comment 10 Timur 2019-11-22 16:04:28 UTC
I guess it's the same issue for other platforms, not Mac specific.
In Windows bug 98452 (regardless the reported issue is duplicate), script run doesn't work anymore.
Comment 11 Stephan Bergmann 2019-11-22 16:20:41 UTC
This issue should be fixed now thanks to the fix for bug 128538.  (Sometimes it takes a while and a second look to spot a solution.)
Comment 12 Stephan Bergmann 2019-11-22 16:30:26 UTC
(In reply to Timur from comment #10)
> I guess it's the same issue for other platforms, not Mac specific.
> In Windows bug 98452 (regardless the reported issue is duplicate), script
> run doesn't work anymore.

(This issue and its fix were specific to macOS indeed.  If you have another issue you claim is not fixed, please (re-)open another bug for that.)
Comment 13 Timur 2019-12-09 17:37:10 UTC
*** Bug 129215 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2019-12-11 13:12:56 UTC
*** Bug 129322 has been marked as a duplicate of this bug. ***
Comment 15 Thomas Maeder 2019-12-15 09:53:52 UTC
(In reply to Stephan Bergmann from comment #11)
I just checked with newly-installed LO 6.3.4.2: the link to folders now works, albeit somewhat differently:
- Before: the folder would open in the Finder.
- Now: the parent folder opens, and the folder is selected.

Whereas I liked the previous variant a bit better, the new one is fine as well. Thanks to all!