Matteo Ipri via shifter-users
2018-07-04 22:32:23 UTC
Hi all,
I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version
2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra
X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs
when comparing the HTML5 client to the Xpra desktop client I use on my Arch
Linux running PC.
The Docker images are based on Ubuntu 17.10 artful and I attach the
Dockerfiles so that my experiments can be reproduced.
To build the images, I run the following commands:
sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/
sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta
path/to/xpra/
To run the containers, I enter the following:
sudo docker run --interactive --tty --rm -p 8080:8080 xpra
sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta
Once a container is running, I open my web browser (Firefox or Chormium)
and navigate to http://localhost:8080.
Once xpra is loaded I have an xterm window in my browser.
So far, so good.
Once I am in xterm I run the command "xdg-open https://xpra.org".
With the stable version of xpra I only get a message in my local terminal
(the one in which I launched the docker container) that says (as expected):
"2018-07-04 21:04:57,471 New unix-domain connection received on
/home/matteo/.xpra/62b2edcf1139-0
2018-07-04 21:04:57,473 Warning: remote end does not accept URLs"
If I connect to the container with the desktop client, I get the pop-up
asking me where to open the link.
With the beta version, using the HTML5 client, Firefox in the container is
launched.
It seems like the xdg-open-forwarding for URLs is broken in the current
beta.
If I connect to xpra beta with the desktop client, I get the pop-up as with
the stable version of xpra.
I can add that xdg-open-forwarding for URLs was working in version
v2.4-r19581 I installed as beta in a container some week ago.
There are two more bugs, that are present in both version of xpra and only
in HTML5 client.
If I run "firefox https://xpra.org" in the remote xterm terminal window,
Firefox launches regularly and the web page loads fine.
If I ctrl+click on a link, for example on About, the link is opened in the
same tab instead of a new one.
If I use the desktop client, the ctrl+click opens the link in a new tab as
expected.
The second bug I found is about some keyboard keys.
If I try to type the "less than" character (<) pressing "shift+," when
using the HTML5 client, I get the "greater than" character (>).
This happens on both stable and beta HTML5 clients, but not with the
desktop client. My keyboard has the US layout and has 104 keys. In the logs
I see that the "us" layout is chosen by xpra and that the ctrl key press is
recognized by xpra.
Other keys with issues are the 4 in the top right corner of the keyboard
(top right corner of the numpad): /, *, - and +. These four are mapped to
the similar keys in the main part of the keyboard, thus when I press "*" I
get "8" and I have to press "shift+*" to get the "*".
Please, let me know if I can help any further in debugging these issues.
Thank you very for your attention,
Matteo Ipri
I wrote a couple of Dockerfiles to test the latest stable (xpra X11 version
2.3.2-r19729 64-bit as of this writing) and the latest beta version (xpra
X11 version 2.4-r19803 64-bit as of this writing) and I found some bugs
when comparing the HTML5 client to the Xpra desktop client I use on my Arch
Linux running PC.
The Docker images are based on Ubuntu 17.10 artful and I attach the
Dockerfiles so that my experiments can be reproduced.
To build the images, I run the following commands:
sudo docker build -t xpra -f path/to/xpra/Dockerfile path/to/xpra/
sudo docker build -t xpra:beta -f path/to/xpra/Dockerfile-beta
path/to/xpra/
To run the containers, I enter the following:
sudo docker run --interactive --tty --rm -p 8080:8080 xpra
sudo docker run --interactive --tty --rm -p 8080:8080 xpra:beta
Once a container is running, I open my web browser (Firefox or Chormium)
and navigate to http://localhost:8080.
Once xpra is loaded I have an xterm window in my browser.
So far, so good.
Once I am in xterm I run the command "xdg-open https://xpra.org".
With the stable version of xpra I only get a message in my local terminal
(the one in which I launched the docker container) that says (as expected):
"2018-07-04 21:04:57,471 New unix-domain connection received on
/home/matteo/.xpra/62b2edcf1139-0
2018-07-04 21:04:57,473 Warning: remote end does not accept URLs"
If I connect to the container with the desktop client, I get the pop-up
asking me where to open the link.
With the beta version, using the HTML5 client, Firefox in the container is
launched.
It seems like the xdg-open-forwarding for URLs is broken in the current
beta.
If I connect to xpra beta with the desktop client, I get the pop-up as with
the stable version of xpra.
I can add that xdg-open-forwarding for URLs was working in version
v2.4-r19581 I installed as beta in a container some week ago.
There are two more bugs, that are present in both version of xpra and only
in HTML5 client.
If I run "firefox https://xpra.org" in the remote xterm terminal window,
Firefox launches regularly and the web page loads fine.
If I ctrl+click on a link, for example on About, the link is opened in the
same tab instead of a new one.
If I use the desktop client, the ctrl+click opens the link in a new tab as
expected.
The second bug I found is about some keyboard keys.
If I try to type the "less than" character (<) pressing "shift+," when
using the HTML5 client, I get the "greater than" character (>).
This happens on both stable and beta HTML5 clients, but not with the
desktop client. My keyboard has the US layout and has 104 keys. In the logs
I see that the "us" layout is chosen by xpra and that the ctrl key press is
recognized by xpra.
Other keys with issues are the 4 in the top right corner of the keyboard
(top right corner of the numpad): /, *, - and +. These four are mapped to
the similar keys in the main part of the keyboard, thus when I press "*" I
get "8" and I have to press "shift+*" to get the "*".
Please, let me know if I can help any further in debugging these issues.
Thank you very for your attention,
Matteo Ipri