http://bugs.winehq.org/show_bug.cgi?id=57955 --- Comment #5 from Rémi Bernon <rbernon(a)codeweavers.com> --- In its window procedure WM_WINDOWPOSCHANGED handler the application does: dpi = GetDpiForWindow(hwnd); style = GetWindowLongW(hwnd, GWL_STYLE); ex_style = GetWindowLongW(hwnd, GWL_EXSTYLE); menu = GetMenu(hwnd); RECT adj = {0}; AdjustWindowRectExForDpi(&adj, style, menu != 0, ex_style, dpi); RECT client; GetClientRect(hwnd, &client); client.right += (adj.right - adj.left); client.bottom += (adj.bottom - adj.top); client.bottom += 4; SetWindowPos(hwnd, 0, 0, rect.right, rect.bottom, SWP_NOMOVE); This causes the window rectangle to grow vertically until it reaches the maximum vertical window size. At that point, the application stops doing this, but also ends up returning a client rect == window rect from its WM_WINDOWPOSCHANGING handler, which causes the window decorations to be removed. Depending on the window size and on the Linux window manager decision, this can even end up in a infinite window decoration addition / removal loop, which makes the application fully unusable. The latter part is probably just a bogus behavior caused by reaching a corner case and I suspect that the issue comes from the client.bottom += 4 adjustment that is being made in the first place and which triggers the vertical growth. I don't really understand why that adjustment is being made but I suspect it is related to the menu bar itself. On windows the menu is styled differently, and I think the adjustment is meant to compensate some missing vertical size that AdjustWindowRect doesn't or should take into account. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.