[Libreoffice-bugs] [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)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=128522

--- Comment #9 from Stephan Bergmann <sbergman at redhat.com> ---
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200610/e93f8a8c/attachment-0001.htm>