the error msg "file:///G:/…"is not an absolute uRL that can be passed… is misleading. It happens simply when the path does not exist, eg, because the file has been renamed.
If the file is missing, just say 'path does not exist' instead of this complicated and abstruse message about some absolute URL…
We have bug 125607. And message is not wrong like you say here. Please give exact situation and attach example files.
Created attachment 156069 [details] file with frame
[Automated Action] NeedInfo-To-Unconfirmed
Please don't assume that someone will guess what you meant, and explain steps, experienced and expected results.
(In reply to Timur from comment #5) > Please don't assume that someone will guess what you meant, and explain > steps, experienced and expected results. Maybe I forgot to make this comment —sorry: Open URL.odt. Format>Frame&Object>Properties, tab Hyperlink, Browse; choose any file in your computer —eg, a .txt file; hit OK. ^click the frame: the text file opens (eg, via Notepad), which (presumably) implies that the URL is 'absolute' and 'can be passed…'. Reopen the hyperlink property, change the filename to a non-existent one —eg, alter one character; hit OK. ^click the frame: The error msg pops. Yet, the problem has nothing to do with the URL not being 'absolute'; it is just that the file does not exist.
For missing .ODT, .ODP.. hyperlink message is correct: file does not exist. It's just for missing .TXT (I can't say for what else) that I get wrong error as reported. Tested only in Windows. No repro 6.0, repro Lo 6.1 and LO 6.5+.
Bibisected with win32-6.3 to https://git.libreoffice.org/core/+/d59ec4cd1660410fa1b18c50d2d83b1417a82ddc%5E!/ Filter out problematic file URLs Adding Cc: to Stephan Bergmann
The behavior changed from a Windows-provided message box which (at least on my machine) reads Windows cannot find 'C:\nada.odt'. Make sure you typed the name correctly, and then try again. to a LibreOffice-provided message box which reads "file:///C:/nada.txt" is not an absolute URL that can be passed to an external application to open it. And at least technically, the new message is still correct: It states that the given data lacks at least one of two qualities, namely that it is an absolute URL and that it can be passed to an external application. The given data <file:///C:/nada.txt> has the first quality, but lacks the second. <https://git.libreoffice.org/core/+/d59ec4cd1660410fa1b18c50d2d83b1417a82ddc%5E!/> "Filter out problematic file URLs" was meant to address security issues, which explains its rather opaque commit message. What technically happens is that before the change, the data was unconditionally passed to the ShellExecuteEx Windows system function (so Windows responded with the "Windows cannot find ..." message box), while after the change the given data is first put through various checks, and only if it passes all of them is it passed to ShellExecuteEx. One of the checks indirectly tests for existence of the file denoted by the given data, and fails if it does not exist. There is only a single failure channel (throwing a css::lang::IllegalArgumentException) from the code doing the checks and calling ShellExecuteEx if appropriate (CSysShExec::execute in shell/source/win32/SysShExec.cxx) to the initiating code that reports failure (URITools onOpenURI in sfx2/source/appl/openuriexternally.cxx), so the latter responds with a somewhat generic message to all of the various failure causes. (And again, that the given file does not exist isn't even explicitly checked for, it only indirectly causes one of the checks to fail.) Maybe the best solution would be to improve that somewhat generic failure message (STR_NO_ABS_URI_REF in include/sfx2/strings.hrc).
(In reply to Stephan Bergmann from comment #9) > Maybe the best solution would be to improve that somewhat generic failure > message (STR_NO_ABS_URI_REF in include/sfx2/strings.hrc). See <https://gerrit.libreoffice.org/c/core/+/95992> "tdf#128522: Improve wording of failure message". Discussion welcome there.
"file:///C:/nada.txt" cannot be passed to an external application to open it (e.g., it might not be an absolute URL, or might denote no existing file). This sounds quite technical. Why not go with the Windows-style message "LibreOffice cannot find 'C:\nada.odt'. Make sure you typed the name correctly, and then try again." I doubt that ordinary Windows users know what absolute URLs are and wonder why a website (aka URL) is questionable in case of a file. Some alternatives: "LibreOffice cannot access 'C:\nada.odt'. Make sure path and file name comply with your operating system." "Reading data from 'C:\nada.odt' is not possible. Please read the help if you are sure the name has been written correctly." "Path or file does not exists. Please check your input." (see c1) I struggle with "pass to external application". It means this URL can be used internally but not when Windows comes into play. Sounds like a blame game. In the end, users need to know what to change in order to achieve the goal, which is not clear to me.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/15c599aaf28a528ba8e913abadf56da225e31b5b tdf#128522: Improve wording of failure message It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug appear not to be resolved yet, it have a NEW status. Bergmann?...
(In reply to BogdanB from comment #13) > This bug appear not to be resolved yet, it have a NEW status. Bergmann?... oh, can't remember why I didn't set it to RESOLVED FIXED when I pushed the fix in comment 12