Google Chrome window does not run borderless

[totaam]

Issue migrated from trac ticket # 765

component: core | priority: major | resolution: fixed | keywords: chrome borderless window decoration

2014-12-22 18:33:57: i336_ created the issue

---

Using Xpra client version 0.4.12 on Slackware 14.0 (with Openbox), server version 0.12.3 on Ubuntu 14.04.

With Chrome running its default mode with a custom titlebar, it looks like chrome_openbox_window.png.

Both visible Maximize buttons work, and maximize the window; from there, Openbox recognizes that the window has been maximized, but Chrome itself does not, and still shows a "maximize" button, as in chrome_openbox_maximized.png. Once the window is maximized, the Maximize button now does nothing (visible).

Openbox's Minimize button minimizes the window as expected, but Chrome's does nothing when clicked.

Chrome's Close button closes windows correctly.

I'm very happy to run further tests and provide any other information that may be useful.

[totaam]

2014-12-22 18:34:39: i336_ uploaded file chrome_openbox_window.png (265.3 KiB)

[totaam]

2014-12-22 18:35:06: i336_ uploaded file chrome_openbox_window_maximized.png (319.4 KiB)

[totaam]

2014-12-23 06:14:19: totaam changed status from new to assigned

[totaam]

2014-12-23 06:14:19: totaam changed owner from antoine to totaam

[totaam]

2014-12-23 06:14:19: totaam commented

---

I eventually found that chromium's x11_util.cc uses MotifWmHints to disable decorations.

So r8270 + r8271 adds suppport for the _MOTIF_WM_HINTS property, and we now pass the "decorations" flag to the client.
We may even be able to remove some of the heuristics found in #766 / #762 now?

Not yet solved is the problem with minimize and maximize buttons not doing anything...

[totaam]

2014-12-23 12:42:13: totaam commented

---

As for minimizing and maximizing, here's the code that I found in chromium's desktop_window_tree_host_x11.cc:

void DesktopWindowTreeHostX11::Minimize() {
  ReleaseCapture();
  XIconifyWindow(xdisplay_, xwindow_, 0);
}

void DesktopWindowTreeHostX11::Restore() {
  should_maximize_after_map_ = false;
  SetWMSpecState(false,
                 atom_cache_.GetAtom("_NET_WM_STATE_MAXIMIZED_VERT"),
                 atom_cache_.GetAtom("_NET_WM_STATE_MAXIMIZED_HORZ"));
  if (IsMinimized())
    ShowWindowWithState(ui::SHOW_STATE_NORMAL);

XIconifyWindow, we meet again (see also #726).
In some cases, the clicks just aren't registered by chrome at all. Not sure why. Could be a separate issue.

When they are, the minimize buttons seems to trigger this event:

do_xpra_client_message_event(<X11:ClientMessage {'delivered_to': '0xa00001', 'send_event': 1, 'format': 32, \
    'data': (3, 1286, 24, 1714787328, 1439599504), 'window': '0xa00001', 'type': 33, 'serial': '0x21673', \
    'message_type': 'WM_CHANGE_STATE', 'display': ':10'}>)

Which we now handle correctly as of r8272 - which could be backported, but seeing how prone to breakage these changes are (#766).. I'm not sure.

And for the maximize button:

x_event_filter event=('xpra-client-message-event', None)/ClientMessage window=0xa00001
_NET_WM_STATE: _NET_WM_STATE_MAXIMIZED_VERT
_NET_WM_STATE_MAXIMIZED_VERT: atom2=_NET_WM_STATE_MAXIMIZED_HORZ
do_xpra_client_message_event(<X11:ClientMessage {'delivered_to': '0xa00001', 'send_event': 1, 'format': 32, \
    'data': (1, 246, 247, 1, 0), 'window': '0xa00001', 'type': 33, 'serial': '0x21e79', \
    'message_type': '_NET_WM_STATE', 'display': ':10'}>) window maximized=True

Even when we click it repeatedly, it seems that chrome doesn't see it as maximized yet, so it keeps asking us to make it maximized... Will fix.

[totaam]

2014-12-23 15:10:56: totaam commented

---

Maximize should be fixed in r8274 - should be backported (we weren't setting the correct window state, so chrome was thinking we weren't honouring the maximize and therefore never giving us the opportunity to unmaximize..)

But this is not the end of our problems: we also need to handle _NET_WM_MOVERESIZE (and whilst we're at it, maybe also _NET_MOVERESIZE_WINDOW)

[totaam]

2014-12-23 16:23:29: antoine uploaded file initiate-moveresize.patch (9.3 KiB)

attempt at supporting _NET_WM_MOVERESIZE

[totaam]

2014-12-23 16:36:02: totaam commented

---

Added support for _NET_WM_MOVERESIZE in r8275 + r8276 - although this adds a new message type (initiate-moveresize) this could also be backported to v0.14.x with care (and after waiting + testing a bit more). This was more important now that we disabled window decorations for chrome because this also disabled client-side window manager resizing..

Only leaves _NET_MOVERESIZE_WINDOW.

[totaam]

2014-12-24 15:46:04: totaam changed status from assigned to new

[totaam]

2014-12-24 15:46:04: totaam changed owner from totaam to i336_

[totaam]

2014-12-24 15:46:04: totaam commented

---

Added support for _NET_MOVERESIZE_WINDOW in r8277 (includes a test app) - could also be backported.

i336_: does trunk work OK for you?

[totaam]

2014-12-25 11:41:11: antoine commented

---

Backported the iconification support (the easy part) in 8281.

The problem is that if I add the motif hints support (applications that don't want window decorations to be shown), then we also need the maximized changes and also probably the moveresize bits.. And it becomes a bit big for the stable branch - even though it seems more correct.

[totaam]

2014-12-26 11:05:57: totaam commented

---

r8292 makes us support changes to the "decorations" flag - should be backported. This can be tested with the "transparent colors" test app by clicking on the window, which toggles window decorations on and off.

See also #537 for maximize.

[totaam]

2014-12-28 13:15:21: totaam commented

---

Also needed: r8317 to advertise the capability to applications.

[totaam]

2014-12-30 07:59:37: totaam commented

---

As per #762 / #766: this needs to be backported sooner rather than later as there is no other way to "do the right thing" when it comes to window decorations.

[totaam]

2014-12-30 11:36:58: totaam changed status from new to assigned

[totaam]

2014-12-30 11:36:58: totaam changed owner from i336_ to totaam

[totaam]

2014-12-30 11:36:58: totaam commented

---

Almost everything (except the map / unmap code) was backported in 8336 + 8337 (+ minor fixes and tweaks in r8339, 8340, 8341 + 8342).

Remaining problems:

• chrome still has a window grab when we release the mouse.. (still showing the resize cursor) - looks like we may have to send a _NET_WM_MOVERESIZE_CANCEL when the mouse click is released?
• what can we do on OSX and win32 which do not have _NET_WM_MOVERESIZE? maybe we will need to implement the initiate_moveresize function by grabbing the cursor and resizing the window ourselves... (could also be used on Linux for desktop environments which do not advertise support for it)

[totaam]

2014-12-30 13:06:12: antoine uploaded file moveresize-buttontracking.patch (2.0 KiB)

adds button tracking so we can release buttons that were pressed to trigger the moveresize

[totaam]

2014-12-30 13:07:36: antoine commented

---

Scratch the "chrome still has a window grab": it does, but that's not a problem with xpra... took me a while to figure that one out!
Happens with LXDE too.
The patch above may be worth keeping, games and such may want to always get the matching events?

[totaam]

2014-12-30 17:09:13: totaam commented

---

Beta 0.14.16 and 0.15.0 packages with all these changes can be found here: [http://xpra.org/beta/]

i336_: any kind of testing feedback would be much appreciated.

[totaam]

2015-01-02 10:43:38: totaam commented

---

I am moving the win32 and osx support for _NET_WM_MOVERESIZE to #772 and closing this ticket.

[totaam]

2015-01-02 10:43:51: totaam changed status from assigned to closed

[totaam]

2015-01-02 10:43:51: totaam changed resolution from ** to fixed

[totaam]

2015-10-21 09:13:53: John1221 commented

---

I think Chrome windows should have 2 choices: border or borderless. I can resize Chrome windows if it run border.

[totaam]

2016-09-14 17:24:10: antoine commented

---

FYI: latest builds have move-resize support, see #772