xpra icon
Bug tracker and wiki

Opened 10 months ago

Closed 9 months ago

#1774 closed defect (worksforme)

html5 clients does not connect, goes to xpra.org instead

Reported by: mviereck Owned by: mviereck
Priority: major Milestone: 2.3
Component: html5 Version: 2.2.x
Keywords: html5 url Cc:

Description

Hello,

I am testing xpra html5 capabilities and found some issues with the html5 client https://xpra.org/html5/connect.html. If I type in IP and port, it does not connect. Instead, it leads to xpra.org main page.

If typing in IP:PORT directly in the browser, the connection works.

Strange workaround: if I connect to the same IP:PORT in two browsers at the same time (firefox and chromium), the first connection is disconnected and shows the html5 client. If I click "connect" here, it works. (Of course, the other browser is disconnected than).

Maybe related: This way I can use the html5 client and choose some options. Especially I am trying different audio codecs. This works until for some unknown reason the connection breaks and is automatically reconnected. The options chosen in html5 client formular are lost after reconnection.

Unfortunately, a working connection does not show the URL parameters I could use instead of the html5 client formular. I tried xpra info | grep argv, but it only shows the URL ending with /index.html, but without parameters like ?sound=on. Getting a working URL with parameters would be a great help, but I found no documentation. The ?sound=on option I found in a ticket.

xpra server v2.2.4-r18312 in a debian 9 docker image
Tested with Mozilla Firefox 53.0 and Chromium 64

Change History (5)

comment:1 Changed 10 months ago by Antoine Martin

Status: newassigned

If I type in IP and port, it does not connect. Instead, it leads to xpra.org main page.

Trivial fix in r18626: use a relative URL. But why are you using this copy of the client instead of the one already built into your xpra server?

... the first connection is disconnected and shows the html5 client.

Yes, just use the builtin client. Open your browser and point it at your xpra server, that's all.

The options chosen in html5 client formular are lost after reconnection.

I'll take a look. Those are stored on the session and should not get lost.

Unfortunately, a working connection does not show the URL parameters I could use instead of the html5 client formular.

They are stored on the session and do not leave the client (which is important for things like username and password).

Getting a working URL with parameters would be a great help, but I found no documentation.

There is none, those parameters are subject to change, you can find them in the page source.

comment:2 Changed 10 months ago by Antoine Martin

Owner: changed from Antoine Martin to mviereck
Status: assignednew

The options chosen in html5 client formular are lost after reconnection.

I can't reproduce this problem. Please provide steps.

The only problem that I found was with sound forwarding which was being turned off the connect page, and that is fixed in r18631.
The other options show up as they were on the connect form.

Tested with:

  • change some values on the connect form
  • connect
  • issue "xpra disconnect" to make the html5 client go back to the connect form

comment:3 Changed 10 months ago by mviereck

Trivial fix in r18626: use a relative URL.

Now it does not go to xpra.org, but the connection fails. (Not found/ Apache Server at xpra.org Port 443). Maybe because I use a localhost connection and it cannot be resolved. Not an issue for me now as I now know how to connect my own xpra server directly.

But why are you using this copy of the client instead of the one already built into your xpra server?

I did not know how to do that; the wiki page only tells me about https://xpra.org/html5/connect.html. It was not obvious to me that I can connect with IP:PORT/connect.html. The wiki page could mention that explicitly.

The only problem that I found was with sound forwarding which was being turned off the connect page, and that is fixed in r18631.

Loosing the sound forwarding option was the one issue I observed, I did not check the others. Though, I loose this still in r18646. (Trying with two alternating connections in chromium to enforce broken connection). I don't know how it will behave on automatical reconnections, currently that does not happen anymore.

comment:4 Changed 10 months ago by Antoine Martin

Now it does not go to xpra.org, but the connection fails.

Then your server IP / port or login credentials are incorrect. (r18647 will now make us go back to the connect form reliably, even when hosted in a subdirectory like is the case with the one at https://xpra.org/html5/connect.html)

Be aware that if you use https for the form, the HTML5 client will try to use SSL when connecting to your target server, which will fail unless you have valid SSL certificate installed. If that's the case, try loading it with an http connection instead: http://xpra.org/html5/connect.html

I did not know how to do that; the wiki page only tells me about https://xpra.org/html5/connect.html. It was not obvious to me that I can connect with IP:PORT/connect.html. The wiki page could mention that explicitly.

It did already, I have now moved things around so the first link that you see refers to your local server: https://xpra.org/trac/wiki/Clients/HTML5?action=diff&version=21.

Though, I lose this still in r18646.

Odd. Maybe your browser needs a refresh.
The only way this option can end up not checked is if:

  • the option was disabled when the connect form was last used
  • the code finds no valid codecs (that was the previous bug fixed in r18631)

comment:5 Changed 9 months ago by Antoine Martin

Milestone: 2.3
Resolution: worksforme
Status: newclosed
Note: See TracTickets for help on using tickets.