Wrong window position with JavaFX

[totaam]

Issue migrated from trac ticket # 1802

component: html5 | priority: major | resolution: invalid

2018-04-05 10:21:34: predkambrij created the issue

---

Hi.

I saw some issues that are related, but I didn't find the exact one, so I apologize if this is a duplicate. I found, that when using --html5, window position of JavaFX application is at bottom right (regardless of browser window size).
I attached monkey patch which fixes this issue (override window position to x=0, y=0).

Test command (which works without patch):
xpra start --exit-with-children=yes --daemon=no -z0 :1 --bind-tcp=0.0.0.0:8080 --html=on --start-child='xeyes'

Test command of JavaFX application (which hash wrong window position without of the patch):
xpra start --exit-with-children=yes --daemon=no -z0 :1 --bind-tcp=0.0.0.0:8080 --html=on --start-child='java -jar /tmp/demos/jdk1.8.0_161/demo/javafx_samples/Modena.jar'

[[BR]]
System info:

- tested in docker container centos:7.3.1611
- output of showconfig in the attachment

$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
[builder@achict ~]$

$ xpra --version
xpra v2.2.6-18968

Regards

[totaam]

2018-04-05 10:22:24: predkambrij uploaded file xpra_window.patch (0.4 KiB)

[totaam]

2018-04-05 10:22:35: predkambrij uploaded file showconfig.out (9.3 KiB)

[totaam]

2018-04-05 10:23:10: predkambrij changed component from android to html5

[totaam]

2018-04-07 10:12:10: antoine changed status from new to closed

[totaam]

2018-04-07 10:12:10: antoine set resolution to invalid

[totaam]

2018-04-07 10:12:10: antoine commented

---

Java is known to do weird things with how it manages its windows.
In this case, running this "Modena" example, it:

• creates a 1x1 window:

initial X11 position and size: requested((0, 0, 1, 1), {'minimum-size': (0, 1), 'maximum-size': (32767, 32730), 'gravity': 1})=(0, 0, 1, 1)

• resizes it to its actual size (1024x768) then tells the window manager to move it to 768x227:

do_child_configure_request_event(<X11:ConfigureRequest \
    {'delivered_to': '0x44', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 1, 'width': 1, \
     'window': '0xc00003', 'above': 0L, 'y': 227, 'x': 768, 'serial': '0x6a5', 'border_width': 0, \
     'value_mask': 3L, 'display': ':10'}>) \
    client=0xc00003, corral=0x400037, value_mask=X|Y, size-hints={'minimum-size': (0, 1), 'maximum-size': (32767, 32730), 'gravity': 1}
updateprop(requested-position, (768, 227)) previous value=(0, 0)
updateprop(geometry, (768, 227, 1024, 768)) previous value=(0, 0, 1024, 768)

With some extra calls I have omitted here (ie: figuring out the frame extents, etc)
So basically, it figures out the center of the vfb and places its window there.

And this is exactly what we honour in the client, both in the python client and in the html5 client.
Except the window manager then ensures that the window is at least partially visible if the coordinates end up off-screen.
So, we won't be fixing this in xpra, but you have some workarounds available:

• start the Java application after the client connects, so that the vfb size will be matching that of the client and it will then appear right in the center - ie: use --start-after-connect=java -jar ...
• use a smaller initial vfb size, ie: XPRA_DEFAULT_VFB_RESOLUTION=1024x768 xpra start ...

[totaam]

2018-04-09 09:29:52: predkambrij commented

---

Hi

Thank you for the feedback. The second workaround doesn't work for me, but the first one does, but it has different behavior (obviously).

Br