undecorated windows should not cover the taskbar when maximized on win32

[Antoine Martin]

See 762#comment:15.

Reproducible with the simple test maximized app.

OTOH, options:

• don't use GTK's maximized state (only on win32?) and track it ourselves, which will allow us to maximize using dimensions we can calculate
• extend the 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:

• ​Prevent Maximized WPF Window from Covering Taskbar
• ​Maximizing window (with WindowStyle=None) considering Taskbar

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..

[Antoine Martin]

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):

• we figure out which monitor the window is on (we rely on the API to choose the right one if it covers more than one.. hoping that this is the one it will be maximized on!) using win32api.MonitorFromWindow(handle, MONITOR_DEFAULTTONEAREST)
• we calculate the workarea for that monitor using win32api.GetMonitorInfo(monitor)
• we choose the smaller max-size between the one given by the application and the workspace size
• we apply this restriction via the existing MINMAXINFO hook
• we now also take into account if the window is decorated or not when calculating the window max size

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)

[Antoine Martin]

(editing milestone)

[John1221]

Yes, it's work. I've just tested with beta 0.15 r8603 package.
PS: Sorry for the late response.

[Antoine Martin]

afarr: re-assigning to you for testing / ack.

[alas]

• Testing with 0.15.0 r8622 windows client against 0.15.0 r8601 fedora 20 server.

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).

[John1221]

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

[Antoine Martin]

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.

[alas]

All of the above seems to be fixed on windows 8.1.

Closing.

[John1221]

This occurred again when running xpra version 0.15.4-1(r10209) for both server(trusty amd64) and client(Win 7 64bit).

[Antoine Martin]

I cannot reproduce with the latest beta 0.16 builds or with 0.15, or even mixing those two versions.

How I tested:

• launch test_window_states.py
• click undecorate
• click maximize

@John1221: please provide more details.

[John1221]

Xpra server info, system info, screenshot

[John1221]

I've just added all infos I know. Include screenshot, xpra server info. If I miss something, please tell me.

[John1221]

I've just added all infos I know. Include screenshot, xpra server info. If I miss something, please tell me.

[Antoine Martin]

server info file extracted from the rar file

[Antoine Martin]

screenshot 1 extracted from the rar file

[Antoine Martin]

screenshot 2 extracted from the rar file

[Antoine Martin]

System info extracted from the rar file

[Antoine Martin]

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?

[John1221]

I forgot my title bar is not the default location.
And I reproduce again, it still happen if the bar is on the bottom.

[Antoine Martin]

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?

[John1221]

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.

[Antoine Martin]

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