Bug 7265 - Server-side resize when Windows client is maximized causes a freeze
Summary: Server-side resize when Windows client is maximized causes a freeze
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client platforms (show other bugs)
Version: trunk
Hardware: PC Windows
: P2 Normal
Target Milestone: 4.12.0
Assignee: Pierre Ossman
URL:
Keywords: aleta_tester, relnotes
Depends on:
Blocks:
 
Reported: 2018-10-29 13:41 CET by Samuel Mannehed
Modified: 2020-03-27 12:35 CET (History)
2 users (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Samuel Mannehed cendio 2018-10-29 13:41:24 CET 
Steps to reproduce:

1. Set the native Windows client to "Resize remote session to the local window"
2. Maximize the client window (not fullscreen)
3. Increase the size of the session: xrandr -s 1920x1200

No errors in xinit.log, no errors in tlclient.log

Could reproduce both with nightly build 5946 client and 4.9.0 client on Windows 10, both when connecting to a build 5942 server and when connecting to a 4.9.0 server.
Comment 1 Pierre Ossman cendio 2018-10-30 12:56:33 CET 
The problem could not be reproduced on macOS or Linux.

Also note that it's the graphics updates that stop, but the client is otherwise still responsive. E.g. the F8 menu still works.

Doing another resize fixes the issue.
Comment 3 Pierre Ossman cendio 2020-03-16 11:20:33 CET 
I did some debugging and this is some form of FLTK bug. It stops calling draw() when this scenario happens.

The issue has to do with Fl_X::wait_for_expose being set. It's not clear how this magic is supposed to work, but it seems to be waiting for some WM_PAINT message that isn't showing up as expected. Until then it blocks all updates for the window.
Comment 4 Pierre Ossman cendio 2020-03-16 13:41:10 CET 
I've pinpointed the issue, and there is unfortunately an architectural issue with FLTK and resize handling:

https://github.com/fltk/fltk/issues/65

However since this only happens when maximized we might be able to work around it.
Comment 6 Pierre Ossman cendio 2020-03-26 10:17:21 CET 
We seem to be able to avoid this issue if we just avoid trying to resize whilst maximized. And fiddling with the window size when maximized is probably not what the user wants anyway, so it's probably a good general fix.
Comment 8 Alex Tanskanen cendio 2020-03-27 12:25:02 CET 
With the latest client build (6429) this it doesn't freeze. This is now fixed for Windows 10. Tested macOS and Linux make sure this fix didn't cause any regression for fullscreen options. Also checked the release notes and it looks good so closing this bug.
Comment 9 Alex Tanskanen cendio 2020-03-27 12:35:17 CET 
(In reply to Alex Tanskanen from comment #8)
> 
> Tested macOS and Linux make sure this fix didn't cause
> any regression for fullscreen options. 
>
 
I of course meant Maximized options and not fullscreen.
Note You need to log in before you can comment on or make changes to this bug.