Xpra: Ticket #1809: Remote windows jump back into screen

Hi.

If I have a remote window forwarded by Xpra and for some reason I move it entirely beyond the right edge of the screen, then it immediately jumps back into the screen, on the right side.

To make things more explicit: if the window is 800×600 on a 1920×1200 screen, if I move the window to x=1919, it stays there, but if I move it to x≥1920, then it immediately jumps back to x=1120.

The same happens vertically when I move the window beyond the bottom of the screen.

It happens a lot with Fvwm's viewport scrolling (it is implemented by moving all the windows in the opposite direction): if I have a window on the current screen and I scroll to a screen on the left, the window follows, almost as if it was sticky.

But the problem is not specific to Fvwm: I just reproduced it starting the Xpra client in Xephyr without a window manager and moving the window with xdotool:

DISPLAY=:1 xdotool windowmove 0x200081 1279 10
DISPLAY=:1 xdotool windowmove 0x200081 1280 10

After the first command, the left edge of the window is still visible on the right of the screen. After the second command, the window jumps back immediately. On the other hand, nothing happens if I move the window to a negative position, even way beyond the edge of the screen.

The Xpra version I am using is 0.17.6+dfsg-1+b3 from Debian on both client and server, but I observed the problem with older versions.

The window manager I use is Fvwm but as I explained above the problem can be reproduced without a window manager.

The command line I used to start it was:

xpra --exit-with-children --start-child=xterm start ssh:ssecem:11

The console output is:

2018-04-16 16:08:25,753 Xpra gtk2 client version 0.17.6-r14322
2018-04-16 16:08:25,753  running on Linux debian buster/sid
2018-04-16 16:08:26,448 GStreamer version 1.14 for Python 2.7
2018-04-16 16:08:26,772 PyOpenGL warning: missing accelerate module
2018-04-16 16:08:26,788 OpenGL support is missing:
2018-04-16 16:08:26,788  vendor 'VMware, Inc.' is blacklisted!
2018-04-16 16:08:26,850 failed to instantiate the dbus notification handler:
2018-04-16 16:08:26,850  you may need to start a notification service for 'org.freedesktop.Notifications'
2018-04-16 16:08:26,850  disable notifications to avoid this warning
2018-04-16 16:08:26,862  detected keyboard: rules=evdev, model=pc105, layout=us
2018-04-16 16:08:26,863  desktop size is 1280x800 with 1 screen:
2018-04-16 16:08:26,863   :1.0 (433x271 mm - DPI: 75x74)
2018-04-16 16:08:26,863     monitor 1 (339x212 mm - DPI: 95x95)
Entering daemon mode; any further errors will be reported to:
  /home/cigaes/.xpra/:11.log
2018-04-16 16:08:31,914 Xpra X11 server version 0.17.6-r14322
2018-04-16 16:08:31,914  running on Linux debian buster/sid
2018-04-16 16:08:31,915 enabled remote logging

I do not see anything interesting in ~/.xpra/:11.log.



Mon, 16 Apr 2018 15:24:31 GMT - Antoine Martin: status, description changed; resolution, milestone set

The Xpra version I am using is 0.17.6+dfsg-1+b3 from Debian on both client and server, but I observed the problem with older versions.

This version is fundamentally broken and insecure, do not use. For more information, see wiki/Packaging/DistributionPackages

Unless proven otherwise, window placement is the responsibility of the window manager running on the client - whatever that is. Most window managers will refuse to place windows off-screen, for obvious reasons. You may get more diagnostics by running the client with "-d geometry", but this is unlikely to expose the window manager's window placement policy.


Mon, 16 Apr 2018 15:51:32 GMT - Cigaes:

I just tested with the latest version from 2.2 branch, the problem still happens.

I think you missed that the problem I am reporting happens without window manager. Forget anything I said about Fvwm and please reopen.

Xephyr :1 -screen 1280x800
DISPLAY=:1 xpra --start-child=xterm start ssh:aimlin:11
DISPLAY=:1 xwininfo -root -tree
DISPLAY=:1 xdotool windowmove 0x20006f 1279 10
DISPLAY=:1 xdotool windowmove 0x20006f 1280 10

After the first xdotool, the window is at the edge of the screen. After the second one, the window is in the screen. The problem does not happen with a local window. Therefore, Xpra is doing something wrong.

Console output:

2018-04-16 17:49:37,887 Xpra gtk2 client version 2.2.6-r19015 64-bit
2018-04-16 17:49:37,887  running on Linux Debian stable-updates sid
2018-04-16 17:49:39,669 GStreamer version 1.14.0 for Python 2.7.14 64-bit
2018-04-16 17:49:39,947 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate
2018-04-16 17:49:40,128 Error: gtkgl rendering failed its sanity checks:
2018-04-16 17:49:40,128  vendor 'VMware, Inc.' is blacklisted!
2018-04-16 17:49:40,137 OpenGL support is missing:
2018-04-16 17:49:40,137  vendor 'VMware, Inc.' is blacklisted!
2018-04-16 17:49:40,148 failed to instantiate the dbus notification handler:
2018-04-16 17:49:40,148  you may need to start a notification service for 'org.freedesktop.Notifications'
2018-04-16 17:49:40,148  disable notifications to avoid this warning
2018-04-16 17:49:40,163  keyboard settings: rules=evdev, model=pc105, layout=us
2018-04-16 17:49:40,164  desktop size is 1280x800 with 1 screen:
2018-04-16 17:49:40,164   :1.0 (433x271 mm - DPI: 75x74)
2018-04-16 17:49:40,164     monitor 1 (339x212 mm - DPI: 95x95)
2018-04-16 17:49:40,760 Error: cannot watch for video device changes without pyinotify:
2018-04-16 17:49:40,760  No module named pyinotify
Entering daemon mode; any further errors will be reported to:
  /home/cigaes/.xpra/:11.log

Thu, 19 Apr 2018 15:05:25 GMT - Antoine Martin: status changed; resolution deleted


Thu, 19 Apr 2018 15:06:59 GMT - Antoine Martin: owner, status changed

Please try r19016 with:

XPRA_CLIP_WINDOW_TO_SCREEN=0 xpra attach ...

I am reluctant to make this the default: on some supported platforms, moving the window offscreen may make it inaccessible permanently.


Thu, 19 Apr 2018 15:40:12 GMT - Cigaes:

Thanks for looking into this. Unfortunately it does not seem to change anything.

Looking at the code, I am not overly surprised, since it covers both the left and the right of the screen, while the issue I am reporting happens only on the right.

Is there a documentation on how to work on Xpra's code, i.e. rebuild only what is necessary and run it from there? README only tells how to install.


Thu, 19 Apr 2018 16:22:45 GMT - Antoine Martin:

I am not overly surprised, since it covers both the left and the right of the screen, while the issue I am reporting happens only on the right.

That doesn't make sense to me: the statement removes both checks.

Is there a documentation on how to work on Xpra's code

Try: wiki, specifically: wiki/Building


Thu, 19 Apr 2018 18:30:23 GMT - Cigaes:

Replying to Antoine Martin:

That doesn't make sense to me: the statement removes both checks.


Yes, exactly: since that block of code handles all four borders the same, it is very unlikely to be the cause of something that happens only on two borders. Therefore, I believe the cause of the issue must be somewhere else.


Try: wiki, specifically: wiki/Building


I tried, but I only found instructions for building and installing, not how to do quick change-build-test-change-build-test cycles.

In other words, what the wiki shows is equivalent to make install, while I am looking for the equivalent of make && ./xpra.

From an already built tree, ./setup.py install seems to take about 10 seconds. That is a bit too long to wait after adding a few debug print statements. May I ask how you proceed yourself when testing small changes? My intent is to try and debug this myself, since I have a test case ready and the last commit show where to look.


Thu, 19 Apr 2018 21:50:09 GMT - Cigaes:

Got it. The function responsible for the issue is _clamp_window in src/xpra/x11/server.py. If I disable all its code, the behavior that is annoying me disappears.


Fri, 20 Apr 2018 02:02:47 GMT - Antoine Martin:

what the wiki shows is equivalent to make install, while I am looking for the equivalent of make && ./xpra.

You need the "make install" to ensure all the bits are in place.

From an already built tree, ./setup.py install seems to take about 10 seconds

You can turn off all the things that make it slow to build if you're not testing them (nvenc, html5, etc)

The function responsible for the issue is _clamp_window

This function was added in r11114, try r19021 with:

XPRA_CLAMP_WINDOW_TO_ROOT=0 xpra start :10 ...

(applies to local starts only since env vars are not forwarded during remote server start)

Again, I am reluctant to change the default for now: moving windows offscreen can have undesirable side-effects. What is your use-case for a window that isn't visible but still mapped?


Fri, 20 Apr 2018 12:46:03 GMT - Cigaes:

Replying to Antoine Martin:

This function was added in r11114, try r19021 with:

XPRA_CLAMP_WINDOW_TO_ROOT=0 xpra start :10 ...

(applies to local starts only since env vars are not forwarded during remote server start)


It works perfectly, thanks.


Again, I am reluctant to change the default for now: moving windows offscreen can have undesirable side-effects.


I can understand that. Could it be a command-line options? These seem to be forwarded. Or a config file option? If not, do not worry too much, I can manage on my own from here.


What is your use-case for a window that isn't visible but still mapped?


This is how Fvwm implements its extended desktop and viewport feature (which is not the same thing as multiple desktops): windows that are outside the viewport are really moved outside of the visible area of the screen, but not unmapped.


Thanks for all your help.


Fri, 20 Apr 2018 13:26:39 GMT - Antoine Martin:

Could it be a command-line options? These seem to be forwarded. Or a config file option?

Could be added, this would require a patch with man page updates, the option parsing code, etc.

This is how Fvwm implements its extended desktop and viewport feature (which is not the same thing as multiple desktops): windows that are outside the viewport are really moved outside of the visible area of the screen, but not unmapped.

We should support fvwm, so the default is now changed in r19029. We still have time to see if this causes any problems, if it does I'll revert the change.

Can I close this ticket?


Fri, 20 Apr 2018 15:12:55 GMT - Cigaes: status changed; resolution set

Thanks.


Sat, 23 Jan 2021 05:34:21 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1809