xpra icon
Bug tracker and wiki

Opened 5 months ago

Closed 3 months ago

#1894 closed enhancement (fixed)

more url scheme handling

Reported by: Antoine Martin Owned by: J. Max Mena
Priority: major Milestone: 2.4
Component: client Version: 2.3.x
Keywords: Cc:

Description (last modified by Antoine Martin)

  • r3271 added support for URL association, so xpra would be used for opening URLs that look like this: xpra://....
  • r3278 added URL handling on win32
  • r13106 added support for SSL using xpras://.... (inc win32 changes)
  • r12380 equivalent macos bits

See also:

We should support more transport types using a more generic scheme:

  • xpra:// for TCP
  • xpra+ssl:// for SSL
  • xpra+ssh:// for SSH
  • xpra+ws:// for websockets
  • xpra+wss:// for secure websockets

Related: Web-based protocol handlers can be used to register protocols with the browser.

Change History (6)

comment:1 Changed 5 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 5 months ago by Antoine Martin

Description: modified (diff)

As per rfc2396 appendix A: the scheme should start with a letter and can contain letters, numbers, "+", "-" and "."
But it looks like there are compatibility issues with badly written scheme parsers and the "+" character..

Once this is finished, we should register them here: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml.

comment:3 Changed 5 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Smo
Status: assignednew

Done in r19856 and tested on:

  • win32: works fine (used browsers to enter the URL)
  • macos: URL mapping works and it fires xpra, but the client does not connect (unrelated problem): #1905
  • linux: what a load of crap, we added the new URL schemes to the desktop file, and during RPM install we still call:
    /usr/bin/update-mime-database
    /usr/bin/update-desktop-database
    

We still validate the desktop file during rpmbuild.
Yet nothing happens, no warnings, no errors, nothing.
But the URL mapping doesn't take:

$ xdg-open xpra+tcp://192.168.1.7:10000/
gio: xpra+tcp://192.168.1.7:10000/: The specified location is not supported

The "legacy" one still does though:

xdg-open xpras://192.168.1.7:10000/

What on earth do we need to do to get the system to update the mapping?
(and for the record, I've tried "xpratcp", "xpra-tcp" and "xpra+tcp" as schemes - no difference, none get registered)
There will not be a "year of the Linux desktop", it's an endless waste of time.

@smo: please help.

Last edited 5 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 3 months ago by Antoine Martin

So xdg-open just delegates opening URLs and files to other utilities, depending on what OS and DE is running.

In the case of gnome3 that's "gio" which is part of "glib2".
Turning on all debugging with:

G_DBUS_DEBUG=all xdg-open xpra+tcp://host:port/

We get tons of dbus calls, it seems to query org.gtk.vfs.Daemon.
And also org.gtk.vfs.MountTracker ListMountableInfo.

Other scheme types fail in different ways, equally undecipherable.

comment:5 Changed 3 months ago by Antoine Martin

Owner: changed from Smo to J. Max Mena

Well, that's interesting: this problem doesn't occur on any other test systems, only my main development one. PITA.
No amount of running update-desktop-database or update-mime-database does any good.

r20271 fixes URL scheme patching, this will do.

@maxmylyn: the URL in the ticket description should fire xpra on all platforms (with the correct transport type).
ie:

xdg-open xpra+ssl://192.168.1.6:10000/

comment:6 Changed 3 months ago by J. Max Mena

Resolution: fixed
Status: newclosed

Noted and closing.

Note: See TracTickets for help on using tickets.