After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781800 - Strip off hostname from file URIs?
Strip off hostname from file URIs?
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-26 20:40 UTC by Egmont Koblinger
Modified: 2019-02-07 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix v1 (3.76 KB, patch)
2017-04-30 22:15 UTC, Egmont Koblinger
none Details | Review
Fix v2 (4.45 KB, patch)
2017-08-21 19:52 UTC, Egmont Koblinger
none Details | Review

Description Egmont Koblinger 2017-04-26 20:40:32 UTC
As mentioned in the hyperlink bug 779734 comment 120, explicit hyperlinks with "file://" URIs should fill out the hostname (otherwise bad behavior is bound to happen over ssh).

Ctrl+clicking on such an .odt file pops up LibreOffice's splash screen, and then it vanishes and nothing happens.

Turns out, LibreOffice supports cmdline arguments "file:///path/to/file.odt" or "file://localhost/path/to/file.odt", but not "file://the-actual-hostname/path/to/file.odt". It doesn't even care about presenting a useful error dialog.

Is this a bug in LibreOffice? Or in the piece of the GNOME infrastructure that constructs the command line from the URI? I'm wondering how many other apps suffer from this kind of problem.

It's even more compilicated due to the slight disagreement between the RFC and the Freedesktop spec wrt. FQDN or gethostname(), see the aforementioned comment. Maybe LibreOffice just tries to figure out the FQDN and fails on my machine? (I don't have a domainname set, that is, `hostname` and `hostname --fqdn` report the same dot-free string for me.)

Given that gnome-terminal verifies that the hostname is the local host and refuses to open otherwise, I'm wondering: Should it work around these problems by removing the hostname before opening the file: URI?
Comment 1 Egmont Koblinger 2017-04-26 21:25:00 UTC
LibreOffice bug: https://bugs.documentfoundation.org/show_bug.cgi?id=107461
Comment 2 Christian Persch 2017-04-30 20:22:26 UTC
(In reply to Egmont Koblinger from comment #0)
> Given that gnome-terminal verifies that the hostname is the local host and
> refuses to open otherwise, I'm wondering: Should it work around these
> problems by removing the hostname before opening the file: URI?

It would make this work, and I don't see a downside, so my answer would be: yes.
Comment 3 Egmont Koblinger 2017-04-30 22:15:36 UTC
Created attachment 350776 [details] [review]
Fix v1

Something like this... will tidy up a bit before committing, not really in the mood for writing nice code today :)
Comment 4 Egmont Koblinger 2017-08-21 19:52:29 UTC
Created attachment 358091 [details] [review]
Fix v2

Finally the cleanup I've been planning to do for so long.
Comment 5 Egmont Koblinger 2017-08-31 19:48:42 UTC
Submitted.
Comment 6 Egmont Koblinger 2019-02-06 23:33:49 UTC
LibreOffice just fixed this for Unix systems.

However, comments 4, 5 & 7 over there make some apparently good points about the "file" scheme being ambiguous wrt. SMB shares. And maybe we'll have a Windows port one day.

So I'm wondering, maybe we should just leave our workaround in place??
Comment 7 Christian Persch 2019-02-07 11:06:33 UTC
Yes let's keep that for now.