xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 6 years ago

Closed 6 years ago

Last modified 16 months ago

#1163 closed enhancement (fixed)

handle xpra:// urls on osx

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 1.0
Component: platforms Version: trunk
Keywords: osx Cc:


Follow up from #407.

Unfortunately gtk-osx does not wrap the openURL signal.
So we will need to implement this with the application delegate code..

This is all really ugly and does not fit well at all with the way the code is implemented at present: every other platform will give us the file or URL to open as soon as we start the process. Not so on OSX, where we need the event loop to be running before we can get this information using a signal, sigh.
r12380 worked around this for "open-file", it's ugly but it works.

"open-url" currently fires the launcher (as it lives in the same info.plist), maybe we can just hack this class further to launch the regular client with the URL. It's not going to be pretty.

Change History (7)

comment:1 Changed 6 years ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

comment:2 Changed 6 years ago by Antoine Martin

Status: newassigned

See #1277: osx delegate error

comment:3 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

Better links:

Done in r13463 (and found a bug along the way).

For testing on OSX, click on an xpra link in a browser or just run:

open xpra://HOST:IP/?encoding=rgb

@afarr: this is just a FYI, feel free to close.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 years ago by alas

Owner: changed from alas to Antoine Martin

I tried to test from the MacOS directory of a 1.0 r13590, but couldn't seem to get this to work (though, admittedly, I'm not sure what this is supposed to do, exactly).

Running open http://xpra.org/trac/ticket/1290 opens a trac ticket in my default browser, as expected.

Running open xpra://xpra.org/trac/ticket/1290, on the off chance this might be what you mean by "an xpra link", fails.

Setting up a server with --html=on and then trying open xpra://server-ip:port/?encoding=rgb causes the terminal window to get my hopes up by flashing like it is going to do something, but then disappoints me by not succeeding at anything.

Trying to just enter xpra://server-ip:port/?encoding=rgb into a browser triggers a google search, as does trying xpra://xpra.org/trac/ticket/1257.

I'm not sure we have any intention to use this feature, so you could close if you'd like... but if there's some glaringly obvious detail that I'm missing, let me know and I can test some more.

  • Also note, trying to be thorough I also tested for #1277 mentioned above... then, while I had a launcher initiated session active, I tried open xpra:// (ip & port of my server today), which still doesn't open anything in a default browser, but it did trigger a disconnect of the other session and a unknown or invalid packet type: logging from Protocol (tcp socket: server-ip <- client-ip:some-random-number-I-presume-is-a-wss-socket) error on the server side.
Last edited 6 years ago by alas (previous) (diff)

comment:5 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

@afarr: this is for connecting to an xpra server (not a web URL). You don't need to run it from a specific directory as long as you have installed the latest PKG on that OSX system. You do not need to run the server with "html=on".
This also works on Linux, just replace "open" with "xdg-open".
This also works on win32, you can type it in the URL bar of a browser.

If you saw a "disconnect of the other session", then it is (almost) working.
Maybe a different bug is causing a logging packet to be sent before the connection is fully established. r13592 will now log the full "unknown or invalid" packet data with "-d network".
We want to know what that packet contains so we can prevent it, as this could cause us problems even without using the URL handler for launching. This message can also occur if the client is disconnected for another reason, but this should have been logged already - please include the full server output.

comment:6 Changed 6 years ago by J. Max Mena

Resolution: fixed
Status: newclosed

Tested with the latest r13937.pkg:

  • Works as expected

open xpra://ip:port will connect to an Xpra session, if it exists. Feeding it an invalid URL (such as lacking a port) will just open the launcher. If no Xpra server is at a valid ip:port combo, the launcher also opens, but this time giving an error.

NOTE: Connecting to a ip:port combo that doesn't have a server after already having a session will close the first session.

The dozens? of OSX users will be pleased.


repro step:

  • open xpra://ip:port
  • (with the same terminal window, after the previous command returns:
    • open xpra://ip:port

Doing so disconnects the first session.

Last edited 6 years ago by J. Max Mena (previous) (diff)

comment:7 Changed 16 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1163

Note: See TracTickets for help on using tickets.