Bug 128969 - File is not an absolute URL that can be passed to an external application to open it
Summary: File is not an absolute URL that can be passed to an external application to ...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:6.5.0 target:6.4.0.1 target:7.3.0
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks:
 
Reported: 2019-11-22 17:34 UTC by Timur
Modified: 2022-03-07 10:31 UTC (History)
7 users (show)

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


Attachments
screen clip of the "not an absoluter URL that can be passed to external application" (12.44 KB, image/png)
2019-11-24 19:16 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2019-11-22 17:34:21 UTC
In attachment 123341 [details] are Impress file and bat file (wrong practice to attach zipped, but it's already there..).

1. Open ODP
2. On grouped object right click and choose Interaction
3. Browse to set Program from BAT file
4. Run presentation
5. Click object

Expected, like in LO 5.4: bar is run and you see a command prompt echo.

Experienced, test with Lo 6.1 and master LO 6.5+: "file is not an absolute URL that can be passed to an external application to open it"  

I mark Regression.
Comment 1 V Stuart Foote 2019-11-23 19:35:14 UTC
What is status of Tools -> Options -> Load/Save -> General:

'Save URL relative to File system'?

Default is checked enabled.

Looks like checking disabled would use an absolute path.

=-ref-=
https://help.libreoffice.org/6.5/en-US/text/shared/optionen/01010200.html?System=WIN&DbPAR=IMPRESS&HID=cui/ui/optsavepage/relative_fsys#bm_id3151187
Comment 2 Timur 2019-11-24 07:27:13 UTC
'Save URL relative to File system' checked by default.
But regardless, even if I uncheck, the same message. I don't see "relative" working.
This might also be https://bugs.documentfoundation.org/show_bug.cgi?id=125607#c2.
Comment 3 V Stuart Foote 2019-11-24 19:04:38 UTC
Confirming on Windows 10 Home 64-bit en-US (1903) with
Version: 6.3.3.2 (x64)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

The Impress 'Interaction...' dialog interaction.ui was recently Welded [1], but even before that tpaction.cxx got some rework of the string filters.

Reading the code, IIUC the 'Run a program' lb selection and URI string from its input field receives the same 'bDocument' handling to take it through the os/DE File dialog helper to locate the executable.

So either welding, or the changed string filters, or possibly tweaks done for CVE-2019-9847 are preventing the URI from being parsed correctly and we end with the "STR_NO_ABS_URI_REF" error value from [2] showing.

I've tried changing the program called in the batch to something other than command prompt with echos to extend the time used--no affect, still errors with the generic 'not an absolute URL'.

=-ref-=
[1] https://gerrit.libreoffice.org/#/c/69179/

[2] https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/openuriexternally.cxx?r=f853ec31#100
Comment 4 V Stuart Foote 2019-11-24 19:16:04 UTC
Created attachment 156077 [details]
screen clip of the "not an absoluter URL that can be passed to external application"
Comment 5 Caolán McNamara 2019-11-24 20:23:27 UTC
sounds like CVE-2019-9847 (d59ec4cd1660410fa1b18c50d2d83b1417a82ddc) to me on the face of it. Under linux the .bat is opened in a text viewer when I click on it
Comment 6 Caolán McNamara 2019-11-24 20:28:58 UTC
(note that the content of the document complains about the problem fixed in bug 127791)
Comment 7 Stephan Bergmann 2019-11-26 10:26:32 UTC
(In reply to Caolán McNamara from comment #5)
> sounds like CVE-2019-9847 (d59ec4cd1660410fa1b18c50d2d83b1417a82ddc) to me
> on the face of it. Under linux the .bat is opened in a text viewer when I
> click on it

Yes, the change in behavior observed on Windows is a consequence of that fix.  The advertised functionality of Impress' "Format - Interaction... - Action at mouse click: Run program" feature should be defunct more or less severely on the various platforms for quite a while now.
Comment 8 Timur 2019-11-26 10:53:45 UTC
I conclude that report itself is WontFix.
But I'll convert to Documentation.

Clicking Help on Interaction dialog just opens https://help.libreoffice.org/6.5/en-US/text/simpress/main0000.html?System=WIN&DbPAR=IMPRESS.

There's https://help.libreoffice.org/6.5/en-US/text/simpress/01/06070000.html?DbPAR=IMPRESS#bm_id3153246 and I guess it's there that running program should be explained. 

Note: In Help for Interaction I see:
To access this command...
Choose Slide Show - Interaction
On the Drawing toolbar, click Icon Interaction

But there's no Slide Show - Interaction, looks it's in Format - Interaction.

When menus are changed in LO, or some other major changes, Help should be updated.
Comment 9 Stephan Bergmann 2019-11-26 11:45:07 UTC
(In reply to Timur from comment #8)
> I conclude that report itself is WontFix.

I think that's jumping to conclusions prematurely.  I would like to hear some Impress developers' thoughts on the future of that "Run program" feature first.  (And at the very least, if this is turned into WONTFIX we should rename that option to something like "Open external document".)

> But I'll convert to Documentation.

For any (related) documentation issues, I think it is best to file a new bug.
Comment 10 Stephan Bergmann 2019-11-27 08:31:47 UTC
[removing bibisectRequest keyword, as I don't see a need for doing that]
Comment 11 Commit Notification 2019-11-28 12:49:53 UTC
Olivier Hallot committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/help/commit/9c555ed88af27d3187886cf8a2ae13936b62623d

tdf#128969 Fix Impress Interaction Help page
Comment 12 Commit Notification 2019-11-28 12:50:05 UTC
Olivier Hallot committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/help/commit/7dbb56f56f92ffcdea5ccc620a0b064a7eda1dd1

tdf#128969 Fix Impress Interaction Help page
Comment 13 Xisco Faulí 2020-01-20 14:27:43 UTC
A polite ping to Olivier Hallot:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ?
Otherwise, Could you please explain what's missing?
Thanks
Comment 14 Timur 2020-01-20 16:37:18 UTC
Xisco, see Comment 9, I guess Olivier just side improved documentation, but source issue still exists.
Comment 15 Jean-Francois Nifenecker 2021-10-26 05:25:03 UTC
This bug is still present in 7.2.x. and is there for a very long time (I checked v.6.4.7 under windows).

It is *very* annoying, since it prevents from starting a secondary slideshow from the main one.

If the "Run Program" interaction can't be used anymore for that purpose, I'd suggest adding a dedicated interaction "Run slideshow" (unless I'm missing something). The ability to run external/secondary slideshows is a must-have, imo.

I'd set this bug importance as major.
Comment 16 Commit Notification 2021-10-29 11:27:12 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/70009098fd70df021048c540d1796c928554b494

tdf#128969: Let the user explicitly decide to execute an external program

It will be available in 7.3.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.
Comment 17 cv 2022-03-07 10:31:24 UTC
(In reply to Commit Notification from comment #16)
> Stephan Bergmann committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> 70009098fd70df021048c540d1796c928554b494
> 
> tdf#128969: Let the user explicitly decide to execute an external program
> 
> It will be available in 7.3.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.

See my related issue bug 140886

Sadly the patch still isn't working for me. The fix bring up indeed the warning message but seems like that after confirming you want to open it anyway it fails again. As a side note this still work like before: on local filesystem everything works fine (it opens a PDF file) but the same file on a remote filesystem does not open because of the file permission set (and no, spaces or special chars are not the issue, see bug 140886). Will take a look at the source later to try to help find where the issue is.
Tried with the daily build (07/03/22) of LO 7.3 for MacOS.