#846 closed defect (fixed)
JavaFx-Applications starts with wrong size with jdk>=8
Reported by: | Mike | Owned by: | Mike |
---|---|---|---|
Priority: | major | Milestone: | 0.14 |
Component: | core | Version: | trunk |
Keywords: | Cc: |
Description (last modified by )
When I start a JavaFx
application, the application starts with size 0,0. I can then enlarge it (when I find it).
This happens with all JavaFx
applications.
To see that behavior download the samples from: http://www.oracle.com/technetwork/java/javase/overview/javafx-samples-2158687.html
I've tested it with Ensemble:
java -jar Ensemble.jar
My Xpra is compiled from trunk r9187.
Attachments (2)
Change History (13)
comment:1 Changed 6 years ago by
Component: | android → core |
---|---|
Description: | modified (diff) |
Milestone: | → 0.14 |
Priority: | major → critical |
Status: | new → assigned |
comment:2 Changed 6 years ago by
Owner: | changed from Antoine Martin to Mike |
---|---|
Priority: | critical → major |
Status: | assigned → new |
comment:3 Changed 6 years ago by
Please find the -d window
logs attached.
I'm using a gentoo system.
comment:4 Changed 6 years ago by
Please see wiki/ReportingBugs, comment:3 is nowhere near enough information for me to do anything with it.
comment:5 Changed 6 years ago by
Sorry for not providing enough information. The client log was missing due to an error of me.
In the mean time I found out, that the problem is related to the version of the JVM (java virtual machine).
Oracle JDK 1.8.0.45 (also tried 1.8.0.40) has the problem.
Oracle JDK 1.7.0.80 is OK.
Running Ensemble.jar against a "real" X11 server is OK with both JVM versions.
I my tests I saw no dependency to xpra version (tried back to r5826).
I saw no dependency on the client (linux/osx).
Can you try again please by using a java 1.8 jvm?
comment:6 Changed 6 years ago by
Owner: | changed from Mike to Antoine Martin |
---|---|
Status: | new → assigned |
Summary: | JavaFx-Applications starts with wrong size → JavaFx-Applications starts with wrong size with jdk>=8 |
Confirmed with jdk8.
This sounds similar to #705, but sadly, using the wm-name=Sawfish
does not help here.
comment:7 Changed 6 years ago by
Here comes the server -d window
debug log extract for this:
do_child_configure_request_event(<X11:ConfigureRequest \ {'delivered_to': '0x44', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 1, 'width': 1, 'window': '0xa00003', 'above': 0L, 'y': 0, 'x': 0, 'serial': '0x13f0', 'border_width': 0, 'value_mask': 15L, 'display': ':10'}>) Reconfigure on withdrawn window do_child_configure_request_event(<X11:ConfigureRequest \ {'delivered_to': '0x44', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 1, 'width': 1, 'window': '0xa00003', 'above': 0L, 'y': 0, 'x': 0, 'serial': '0x13f8', 'border_width': 0, 'value_mask': 64L, 'display': ':10'}>) Reconfigure on withdrawn window Found a potential client new window 0xa00003 setup() corral_window=0x40007c ... XGetClassHint(0xa00003) classhints: ensemble.Ensemble2, ensemble.Ensemble2 wm_hints.input = 1 _update_client_geometry: using initial size=(1, 1) and position=(0, 0) ... setup() adding to save set setup() reparenting setup() geometry setup() resizing windows to 1x1 adding window WindowModel(0xa00003 - "Ensemble") Discovered new ordinary window: WindowModel(0xa00003 - "Ensemble") (geometry=(0, 0, 1, 1)) ... client configured window 4 - WindowModel(0xa00003 - "Ensemble"), at: (0, 0, 1, 1) _process_configure_window([4, 0, 0, 1, 1, \ {... } old window geometry: (0, 0, 1, 1) _handle_iconic_update: set_state(1) updating metadata on WindowModel(0xa00003 - "Ensemble"): <GParamBoolean 'iconic'> _update_client_geometry: owner()=DesktopManager(2) _do_update_client_geometry: 1x1 _do_update_client_geometry: hints={'minimum-size': (0, 0), 'maximum-size': (32767, 32767), 'gravity': 1} _do_update_client_geometry: size=(1, 1, 1, 1) _do_update_client_geometry: position=(0, 0) ...
So we create a 1x1 window as we're told... Not sure where we're supposed to be getting the "correct" size from.
Could be related to #881.
comment:8 Changed 6 years ago by
Got it, not sure how I missed it earlier.
Using:
XPRA_X11_DEBUG_EVENTS=ConfigureRequest xpra start ...
We see:
ConfigureRequest event 0x6db : <X11:ConfigureRequest \ {'delivered_to': '0x44', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 700, 'width': 1020, 'window': '0xa00003', 'above': 0L, \ 'y': 0, 'x': 0, 'serial': '0x6db', 'border_width': 0, 'value_mask': 12L, 'display': ':10'}> delivering event to parent window: 0x44 (signal=child-configure-request-event) not forwarding to XpraServer handler, it has no child-configure-request-event signal (it has: ('xpra-cursor-event', 'xpra-child-map-event')) forwarding event to a Wm handler's child-configure-request-event signal do_child_configure_request_event(<X11:ConfigureRequest {...}>) value_mask=Width|Height, should be handled by the window model forwarded ConfigureRequest event 0x6db : <X11:ConfigureRequest \ {'delivered_to': '0x44', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 1, 'width': 1, 'window': '0xa00003', 'above': 0L, \ 'y': 291, 'x': 770, 'serial': '0x6db', 'border_width': 0, 'value_mask': 3L, 'display': ':10'}> delivering event to parent window: 0x44 (signal=child-configure-request-event) not forwarding to XpraServer handler, it has no child-configure-request-event signal (it has: ('xpra-cursor-event', 'xpra-child-map-event')) forwarding event to a Wm handler's child-configure-request-event signal do_child_configure_request_event(<X11:ConfigureRequest {...}>) value_mask=X|Y, should be handled by the window model 2015-05-23 22:29:06,579 forwarded
So we get two configure request events: one for (Width|Height) and one for (X|Y), but they are delivered to the root window (0x44) instead of the window model.
And so we then decide to not act on it in Wm (which listens on the root window) because the window model's handler should be dealing with it.
And now we go down the rabbit hole:
- if we forward the event, we still have the problem that
_update_client_geometry
will only honour the update before setup_done and this happens after... - if we disable the setup_done check (not sure that is safe or wise - but heh..), then the geometry change still doesn't get sent to the client because the windows aren't visible yet.
- if we force a "geometry" notification when setup_done when we don't have an "owner" yet
- we find that the position is incorrect:
window.get_position()
still returns 0x0 after we've moved the window to its requested location - looks like a bug, the size is correct as we get the value from theactual-size
property - to prevent resizing loops, the server sends the geometry change via the
size_notify_clients
timer... and by the time it fires, the client has configured the window in its initial size + location (which is 0x0 at 0,0..), so we don't send it
- we find that the position is incorrect:
What a mess!
Changed 6 years ago by
Attachment: | force-forward-configure-request.patch added |
---|
with this hack of a patch, the window shows up with the right size and position
comment:9 Changed 5 years ago by
Owner: | changed from Antoine Martin to Mike |
---|---|
Status: | assigned → new |
comment:10 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I can confirm that it works. I've testet with r11347.
Thanks for fixing!
comment:11 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/846
I cannot reproduce this with 0.14 or with trunk so I am lowering the priority, my desktop environment is cinnamon on Fedora 20.
Please include more details so we can investigate this issue you are having, see wiki/ReportingBugs for guidelines.
It may be worth including the client and server logs with
-d window
.