In seamless mode, moving a window shrinks it 14x7

[chrislong]

When running in seamless mode, moving any window causes that window to shrink by 14 pixels horizontally and 7 pixels vertically. Each move causes this, until the window starts moving across the screen by itself (to the right) when it has focus.

To Reproduce

1. Start xfreerdp in seamless mode
2. Drag an application by its title bar, watching its size (preferably your window manager reports this to you)
3. You should notice the window has gotten smaller. If you measure (e.g., by grabbin the application again if your WM shows you sizes when you do) you will find it's smaller now by 14x7 pixels.
4. If you drag it again, it will shrink the same amount again. Repeat as desired.

Expected behavior
Moving the window does not automatically shrink it.

Screenshots
I can provide these if needed.

** Application details

• Version of FreeRDP
  This is FreeRDP version 2.0.0-rc3 (2.0.0-rc3)

• Command line used
  xfreerdp /v:foo.bar.com /u:auser /p:mypassword /cert-ignore /app:'%windir%\explorer.exe'

• output of /buildconfig
  This is FreeRDP version 2.0.0-rc3 (2.0.0-rc3)
  Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=OFF WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DIRECTFB=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=OFF WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PCSC=OFF WITH_PROFILER=OFF WITH_PULSE=OFF WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=OFF WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_WAYLAND=OFF WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XV=ON WITH_ZLIB=ON
  Build type: RelWithDebInfo
  CFLAGS: -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g
  Compiler: GNU, 7.3.0
  Target architecture: x64

• OS version connecting to
  Windows 10 Enterprise

• If available the log output from a run with /log-level:trace
  It's 27000 lines, so I didn't post it.

Desktop (please complete the following information):

• OS: Linux
• Browser: N/A
• Version: Ubuntu 18.04 LTS

[akallabeth]

@chrislong is this still the case with our nightly builds? There have been a few fixes targeted at rail support.

[chrislong]

Still exists in 2.0.0-rc4 and in the latest nightly (2.0.0-dev5 (531b1b6), aka 2.0.0+020181211024825.6061.gbp531b1b).

[akallabeth]

@benjaminwingert sorry, what do I miss here, this is no freerdp log?

[benjaminwingert]

@benjaminwingert sorry, what do I miss here, this is no freerdp log?

you are right. Wrong topic.
Still I can confirm that the windows are shrinking.
FreeRDP version version 2.0.0-dev5 (f678a91) on Debian 9 (stretch) with Gnome and X11.
Feels like the window decoration gets subtracted from the window size on each move.

[chrislong]

I did some experimentation with wmctrl and discovered that if the window does not have focus when it moves, the shrinking doesn't happen immediately when it's moved, but does when the window gains focus. (This test was with version 2.0.0-dev5 (5b24dc1).)

[chrislong]

After adding a bunch more debugging logging to the X11 and RAIL code, and more experimentation, I cannot find anything that the xfreerdp code is doing wrong. If a window is moved using wmctrl, xfreerdp sends the correct new window dimensions to the server (although it waits until the window gets focus, which seems a bit odd, but should still work). The server then sends back new placement and size for the window, which are wrong (i.e., different from what the client just sent it). I don't know why.

The amount the server moves and resizes the window is affected by HKCU\Control Panel\Desktop\WindowMetrics, though, specifically BorderWidth and PaddedBorderWidth (in the registry on the server). If I change those, the amount the server moves and resizes windows changes. If there were a way to get those values from the server, maybe the offsets could be computed. But as far as I can tell, that information isn't part of RDP.

At this point, the only fix I see is after the client sends a window move and/or resize, to ignore window moves & resizes from the server for a short time (maybe 2 seconds). Or possibly to ignore window moves & resizes from the server if they're small, but that may mess up window dragging. I'd like to have a more principled fix, but without knowing why these offsets are happening or how to compute them, I'm not sure what that would be.

[akallabeth]

@chrislong not sure, but I think there is some capability/setting which the client can send so the server does not do that. It is buried deep in the spec though.

[chrislong]

@akallabeth Thanks, I'll look into it. That would be great. After my last comment, it occurred to me that allowing the server and client to be out of sync may cause other problems. However, I found that sending the same move command again seems to make it "stick" on the server. So I was investigating that. But I'll check the spec for how to disable this behavior.

[chrislong]

@akallabeth I read the [MS-RDPERP] spec and didn't see any relevant capability or setting, but maybe I missed it. Any idea what it is?

[r-barnett]

@chrislong , what is the state of this? I suspect that the commit(s) above have at least some of the changes needed to fix issues I'm seeing with RAIL.

[vega-d]

Fedora Silverblue, FreeRDP version 2.4.1.
I'm using wayland and the issue is still there.

[akallabeth]

this should be fixed (at least against more modern windows servers which support enhanced remote app)
rationale:
the whole issue occurred because the local rail window must be synchronized with the virtual desktop position on the server. Since the X11 API is different enough from the windows API some calls expected to be atomic are not.

with modern enhanced remote app the mode was remodeled so that now each rail window is also only a window on the server and the position no longer needs to be in sync with the server as the server does not care where the window is but only about its size, state and contents.

[alixdeveloper]

I have investigated this issue in the latest version of Windows Server 2022.
This problem still persists and the window continues to shrink when moving on the host machine.

[akallabeth]

@alixdeveloper are you sure you´re running with enhanced rail mode? (highDef rail or however the term is in the config)
just as already explained above, with old rails mode this is more ore less impossible to fix.