Xpra: Ticket #791: undecorated windows can't minimize by left-click in it from the win32 taskbar

Server: Ubuntu 12.04 Client: Windows 7 Xpra: 0.14.18 Chrome can't minimize by left-click in it from the taskbar, and still cause the taskbar go to background when maximized.

Fri, 23 Jan 2015 03:40:32 GMT - John1221: component changed

Fri, 23 Jan 2015 03:43:09 GMT - Antoine Martin: owner, priority, status changed; keywords, milestone set

I believe this regression is caused by r8336: now that we handle correctly the request to skip window decorations specified in the _MOTIF_WM_HINTS (which is used by chrome), GTK seems to make the win32 windows "always on top" and non-minimizable. There is no such problem on X11 (and I haven't tried OSX yet).

the taskbar go to background when maximized

This is a separate issue which already has a ticket: #771, and AFAIK this is not a regression (only one issue per ticket please)

Fri, 23 Jan 2015 03:43:59 GMT - Antoine Martin: summary changed

(removing secondary issue from bug title - tracked in #771)

Fri, 23 Jan 2015 05:24:58 GMT - Antoine Martin: summary changed

Editing bug title: this affects any window without decorations, including the rather simple "test window states" sample app.

Fri, 23 Jan 2015 08:07:40 GMT - Antoine Martin: owner, status changed

Quite similar to #771, touches the same ugly win32 codepaths. The problem also manifested itself as a complete lack of taskbar context menu when right-clicking on that window's taskbar entry.


WS_SYSMENU will show the taskbar for a window. I don't know why GTK removes this flag when we undedorate the window, and now I don't care: we override whatever it does in r8531 + r8532 (and in the process fixed a bug: r8353). This one can safely be backported safely I think. (the code is really quite ugly, but should be safe)

John1221: does this work for you? (new beta posted) afarr: can you break it somehow? osx is worth checking..

Wed, 04 Feb 2015 07:02:29 GMT - John1221: owner changed

totaam: Using beta 0.15 r8603, and it's not work for me.

Wed, 04 Feb 2015 09:02:56 GMT - John1221:

I found that if we open Chrome and then minimize by minimize button => now Chrome can minimize by left-click from win32 taskbar

Wed, 04 Feb 2015 09:41:46 GMT - Antoine Martin: owner changed

I found that if we open Chrome and then minimize by minimize button => now Chrome can minimize by left-click from win32 taskbar

Right, it also works for me if I connect after the google chrome window has already been shown. (ie: disconnecting and re-connecting "fixes" it).

I couldn't figure out what the difference was (some attribute out of sync inside GTK?), so I implemented a "big hammer" in r8617: we just reset the window style attributes every time we get an ACTIVATEAPP event... (as I had noticed that those fire whenever we click on the app in the taskbar)

Note: the first few clicks on the taskbar may just cause the window to be raised/unraised, but eventually it does work. (could certainly be improved: the code is ugly and fragile too)

John1221: does it work well enough for you this time? (if so, please re-assign to afarr)

Wed, 04 Feb 2015 10:22:21 GMT - John1221: owner changed

It's work. Thank you very much.

Fri, 06 Feb 2015 01:18:19 GMT - alas: status changed; resolution set

Testing with windows client 0.15.0 r8622 against fedora 20 0.15.0 r8555 server... yup, minimize and restore from a right click on the taskbar element works delightfully, and likewise maximize (which doesn't cover taskbar).

I'll close the ticket, but with a mention here of the issues in #772, chrome won't resize or move with the versions I am testing with... and I'll mention here before adding to that ticket, clicking the minimize button in the chrome window itself locks the button on, making the window non-responsive until a right click in the taskbar minimizes/restores the window (the window's maximize button works as expected, however).

Sat, 23 Jan 2021 05:06:04 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/791