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.
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
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
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.
(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
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...
(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.
(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:"
... file type:"
Created attachment 152176 [details] Example applescripts & results ...Please see the attached file, as I experienced some formatting problems copying to the commend area.
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 should be fixed now thanks to the fix for bug 128538. (Sometimes it takes a while and a second look to spot a solution.)
(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.)
*** Bug 129215 has been marked as a duplicate of this bug. ***
*** Bug 129322 has been marked as a duplicate of this bug. ***
(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!