xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 4 years ago

#771 closed defect (fixed)

undecorated windows should not cover the taskbar when maximized on win32

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.16
Component: client Version: trunk
Keywords: win32 maximize Cc:

Description

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:

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

Attachments (8)

xpra_ticket_771.rar (233.0 KB) - added by John1221 4 years ago.
Xpra server info, system info, screenshot
Server_Info.txt (113.0 KB) - added by Antoine Martin 4 years ago.
server info file extracted from the rar file
normal.png (152.6 KB) - added by Antoine Martin 4 years ago.
screenshot 1 extracted from the rar file
maximized.png (68.3 KB) - added by Antoine Martin 4 years ago.
screenshot 2 extracted from the rar file
System.txt (11.4 KB) - added by Antoine Martin 4 years ago.
System info extracted from the rar file
xpra_client_output_win32.txt (4.9 KB) - added by John1221 4 years ago.
maximized_chrome_default_taskbar_location.png (68.3 KB) - added by John1221 4 years ago.
normal_chrome_default_taskbar_location.png (70.3 KB) - added by John1221 4 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

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)

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 years ago by Antoine Martin

Milestone: 0.160.15

(editing milestone)

comment:3 Changed 5 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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

comment:4 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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

comment:5 Changed 5 years ago by 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).


comment:6 Changed 5 years ago by John1221

Owner: changed from alas to Antoine Martin

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

comment:7 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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.

comment:8 Changed 5 years ago by alas

Resolution: fixed
Status: newclosed

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

Closing.

comment:9 Changed 4 years ago by John1221

Resolution: fixed
Status: closedreopened

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

comment:10 Changed 4 years ago by Antoine Martin

Owner: changed from alas to John1221
Status: reopenednew

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.

Changed 4 years ago by John1221

Attachment: xpra_ticket_771.rar added

Xpra server info, system info, screenshot

comment:11 Changed 4 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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

comment:12 Changed 4 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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

Changed 4 years ago by Antoine Martin

Attachment: Server_Info.txt added

server info file extracted from the rar file

Changed 4 years ago by Antoine Martin

Attachment: normal.png added

screenshot 1 extracted from the rar file

Changed 4 years ago by Antoine Martin

Attachment: maximized.png added

screenshot 2 extracted from the rar file

Changed 4 years ago by Antoine Martin

Attachment: System.txt added

System info extracted from the rar file

comment:13 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

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?

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by John1221

Changed 4 years ago by John1221

Changed 4 years ago by John1221

comment:14 Changed 4 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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

comment:15 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to John1221

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?

comment:16 Changed 4 years ago by John1221

Owner: changed from John1221 to Antoine Martin

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.

comment:17 Changed 4 years ago by Antoine Martin

Milestone: 0.150.16
Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.