See 762#comment:15.
Reproducible with the simple test maximized app.
OTOH, options:
WM_GETMINMAXINFO
mechanism?
This is made even harder by the lies we get from windows with regards to DPI and pixel coordinates.. (see #163)
Links:
Ended up stumbling upon a similar google chrome ticket with this info:
void ChromeNativeAppWindowViewsWin::EnsureCaptionStyleSet() { // Windows seems to have issues maximizing windows without WS_CAPTION. // The default views / Aura implementation will remove this if we are using // frameless or colored windows, so we put it back here. HWND hwnd = GetNativeAppWindowHWND(); int current_style = ::GetWindowLong(hwnd, GWL_STYLE); ::SetWindowLong(hwnd, GWL_STYLE, current_style | WS_CAPTION);
But reading Window Styles, I see: WS_CAPTION: 0x00C00000L - The window has a title bar (includes the WS_BORDER style). And we don't want the title bar..
Should be fixed in r8530.
It's a bit more involved than I would like. Here's what we now do for undecorated windows (like chrome):
win32api.MonitorFromWindow(handle, MONITOR_DEFAULTTONEAREST)
win32api.GetMonitorInfo(monitor)
MINMAXINFO
hook
A beta win32 build is available for testing.
John1221: Does this work for you?
afarr: This will need to be tested on windows 8 and may cause problems with funny dpi settings. With windows spread across monitors, etc.. For this reason, I don't really want to backport it just yet (though the portion that takes the presence of decorations for calculating the max-size could be backported sooner as this is an obvious fix)
(editing milestone)
Yes, it's work. I've just tested with beta 0.15 r8603 package. PS: Sorry for the late response.
afarr: re-assigning to you for testing / ack.
The Maximize on chrome seems to be working as expected, not covering the taskbar... maximizing and un-maximizing (restoring?) with the maximize button in top right of window as expected.
If I maximize with a right-click on the task bar icon for the chrome window, however, the restore option is greyed out, leaving only the option to minimize (or close) - though the restore button in the top right of the window still works if the window is maximized from the taskbar.
Once maximized with a right click option from taskbar, I then have to minimize from taskbar, after which the restore button is no longer greyed out, but it restores it to maximized, and at that point the window can be restored to a default size (though, again, the buttons top right work). Yes, you read that right: maximize, minimize, restore (to maximized), restore again (to default).
Playing with the dpi settings doesn't seem to alter (or break) the behavior.
With multiple monitors, however, the behavior can't be tested particularly thoroughly because the window can't be moved, or resized (minimized, default, or maximized... those are the only options... and start location is start location is start location).
Starting the chrome application from an xpra session xterm creates a chrome window on the default monitor in a set location (how it is set I didn't investigate), no matter which monitor the xterm is located on at the time of the starting... and maximize/un-maximize behaves the same in such a case, because the secondary display is as-good-as-ignored byt the chrome window.
Having said all that, this ticket seems to be solely concerned with the maximize functionality... so, unless the post-maximize restore functionality when engaged through the taskbar is something you want to keep working on, this ticket can probably be closed.
On that note, I did a semi-quick scan and don't see a ticket for chrome not being re-sizable/moveable... but I suspect I just missed it. Let me know if I didn't miss it and a new ticket ought to be made (or which ticket I should copy those details into).
afarr: I think you forgot re-assigning to totaam. About right-click on the taskbar to show maximize, restore, minimize... in windows 7 or late, I must use Shift + Right-click
If I maximize with a right-click on the task bar icon for the chrome window, however, the restore option is greyed out, leaving only the option to minimize (or close) - though the restore button in the top right of the window still works if the window is maximized from the taskbar.
This should be fixed in r8641.
With multiple monitors, however, the behavior can't be tested particularly thoroughly because the window can't be moved, or resized (minimized, default, or maximized... those are the only options... and start location is start location is start location). (..) On that note, I did a semi-quick scan and don't see a ticket for chrome not being re-sizable/moveable... but I suspect I just missed it. Let me know if I didn't miss it and a new ticket ought to be made (or which ticket I should copy those details into).
Yes, we need #772 implemented for osx and win32..
Until then, there are ways, but nothing easy: xdotool
is one.
But assuming the issue above is fixed, I think we can close this ticket.
All of the above seems to be fixed on windows 8.1.
Closing.
This occurred again when running xpra version 0.15.4-1(r10209) for both server(trusty amd64) and client(Win 7 64bit).
I cannot reproduce with the latest beta 0.16 builds or with 0.15, or even mixing those two versions.
How I tested:
@John1221: please provide more details.
Xpra server info, system info, screenshot
I've just added all infos I know. Include screenshot, xpra server info. If I miss something, please tell me.
I've just added all infos I know. Include screenshot, xpra server info. If I miss something, please tell me.
server info file extracted from the rar file
screenshot 1 extracted from the rar file
screenshot 2 extracted from the rar file
System info extracted from the rar file
Your bar is on the right - which is not the default, so you should mention this first so that we have at least a chance to try to reproduce the problem before we see the screenshot. Does it happen if the bar is in its default location?
The system information looks correct:
$ egrep "screen\[0\].width |screen\[0\].height |workareas" System.txt display.screen[0].height : 768 display.screen[0].width : 1366 gui.workareas : [(0, 0, 1292, 768)]
The bar must be about 74 pixels wide.
Can you post the client's output with -d win32
of just when you maximize the window?
I forgot my title bar is not the default location. And I reproduce again, it still happen if the bar is on the bottom.
Can you reproduce with the latest beta builds? I tried using this test app and it worked fine. What version of chrome are you using?
I'm using Chrome version 46.0.2490.71 (64-bit).
With the latest beta builds (r10921), now Chrome is not cover the bar when maximized. Yes, it worked fine.
There were just too many intrusive changes to backport this to v0.15.x, so I am closing this ticket as fixed for 0.16
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/771