Bug 128522 - Error for non-existing hyperlink .TXT file "path is not an absolute uRL...:" should instead say "file does not exist" (steps in comment 6)
Summary: Error for non-existing hyperlink .TXT file "path is not an absolute uRL...:"...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All Windows (All)
: low minor
Assignee: Stephan Bergmann
Whiteboard: target:7.1.0
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2019-10-31 22:05 UTC by TorrAB
Modified: 2020-12-20 15:22 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:

file with frame (13.61 KB, application/vnd.oasis.opendocument.text)
2019-11-23 23:39 UTC, TorrAB

Note You need to log in before you can comment on or make changes to this bug.
Description TorrAB 2019-10-31 22:05:42 UTC
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.
Comment 1 TorrAB 2019-11-15 04:27:08 UTC
If the file is missing, just say 'path does not exist' instead of this complicated and abstruse message about some absolute URL…
Comment 2 Timur 2019-11-22 16:02:00 UTC
We have bug 125607. And message is not wrong like you say here. 
Please give exact situation and attach example files.
Comment 3 TorrAB 2019-11-23 23:39:26 UTC
Created attachment 156069 [details]
file with frame
Comment 4 QA Administrators 2019-11-24 03:37:30 UTC Comment hidden (obsolete)
Comment 5 Timur 2019-11-24 07:29:43 UTC Comment hidden (obsolete)
Comment 6 TorrAB 2019-11-24 12:06:56 UTC
(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.
Comment 7 Timur 2019-11-24 12:38:51 UTC
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+.
Comment 8 Buovjaga 2020-06-08 17:01:25 UTC
Bibisected with win32-6.3 to https://git.libreoffice.org/core/+/d59ec4cd1660410fa1b18c50d2d83b1417a82ddc%5E!/
Filter out problematic file URLs

Adding Cc: to Stephan Bergmann
Comment 9 Stephan Bergmann 2020-06-10 08:07:39 UTC
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).
Comment 10 Stephan Bergmann 2020-06-10 08:59:00 UTC
(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.
Comment 11 Heiko Tietze 2020-06-10 09:46:26 UTC
"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.
Comment 12 Commit Notification 2020-07-13 00:56:16 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 13 BogdanB 2020-12-19 10:37:26 UTC
This bug appear not to be resolved yet, it have a NEW status. Bergmann?...
Comment 14 Stephan Bergmann 2020-12-20 15:22:12 UTC
(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