#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:
- 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..
Attachments (8)
Change History (26)
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to John1221 |
---|
comment:3 Changed 7 years ago by
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 7 years ago by
Owner: | changed from Antoine Martin to alas |
---|
afarr: re-assigning to you for testing / ack.
comment:5 Changed 7 years ago by
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 7 years ago by
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 7 years ago by
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 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
All of the above seems to be fixed on windows 8.1.
Closing.
comment:9 Changed 7 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 7 years ago by
Owner: | changed from alas to John1221 |
---|---|
Status: | reopened → new |
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.
Changed 7 years ago by
Attachment: | xpra_ticket_771.rar added |
---|
Xpra server info, system info, screenshot
comment:11 Changed 7 years ago by
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 7 years ago by
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 7 years ago by
Attachment: | Server_Info.txt added |
---|
server info file extracted from the rar file
comment:13 Changed 7 years ago by
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?
Changed 7 years ago by
Attachment: | xpra_client_output_win32.txt added |
---|
Changed 7 years ago by
Attachment: | maximized_chrome_default_taskbar_location.png added |
---|
Changed 7 years ago by
Attachment: | normal_chrome_default_taskbar_location.png added |
---|
comment:14 Changed 7 years ago by
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 7 years ago by
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 7 years ago by
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 7 years ago by
Milestone: | 0.15 → 0.16 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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
comment:18 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/771
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
hookA 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)