xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#1802 closed defect (invalid)

Wrong window position with JavaFX

Reported by: predkambrij Owned by: Antoine Martin
Priority: major Milestone:
Component: html5 Version: 2.2.x
Keywords: Cc:

Description

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'


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-r18968

Regards

Attachments (2)

xpra_window.patch (434 bytes) - added by predkambrij 3 weeks ago.
showconfig.out (9.2 KB) - added by predkambrij 3 weeks ago.

Download all attachments as: .zip

Change History (5)

Changed 3 weeks ago by predkambrij

Attachment: xpra_window.patch added

Changed 3 weeks ago by predkambrij

Attachment: showconfig.out added

comment:1 Changed 3 weeks ago by predkambrij

Component: androidhtml5

comment:2 Changed 2 weeks ago by Antoine Martin

Resolution: invalid
Status: newclosed

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 ...
Last edited 2 weeks ago by Antoine Martin (previous) (diff)

comment:3 Changed 2 weeks ago by predkambrij

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

Note: See TracTickets for help on using tickets.