xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 3 years ago

#765 closed defect (fixed)

Google Chrome window does not run borderless

Reported by: i336_ Owned by: Antoine Martin
Priority: major Milestone:
Component: core Version: trunk
Keywords: chrome borderless window decoration Cc:

Description

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.

Attachments (4)

chrome_openbox_window.png (265.3 KB) - added by i336_ 5 years ago.
chrome_openbox_window_maximized.png (319.4 KB) - added by i336_ 5 years ago.
initiate-moveresize.patch (9.3 KB) - added by Antoine Martin 5 years ago.
attempt at supporting _NET_WM_MOVERESIZE
moveresize-buttontracking.patch (2.0 KB) - added by Antoine Martin 5 years ago.
adds button tracking so we can release buttons that were pressed to trigger the moveresize

Download all attachments as: .zip

Change History (20)

Changed 5 years ago by i336_

Attachment: chrome_openbox_window.png added

Changed 5 years ago by i336_

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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

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

comment:2 Changed 5 years ago by Antoine Martin

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.

comment:3 Changed 5 years ago by Antoine Martin

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)

Changed 5 years ago by Antoine Martin

Attachment: initiate-moveresize.patch added

attempt at supporting _NET_WM_MOVERESIZE

comment:4 Changed 5 years ago by Antoine Martin

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.

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

comment:5 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to i336_
Status: assignednew

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

i336_: does trunk work OK for you?

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

comment:6 Changed 5 years ago by Antoine Martin

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

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.

comment:7 Changed 5 years ago by Antoine Martin

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.

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

comment:8 Changed 5 years ago by Antoine Martin

Also needed: r8317 to advertise the capability to applications.

comment:9 Changed 5 years ago by Antoine Martin

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.

comment:10 Changed 5 years ago by Antoine Martin

Owner: changed from i336_ to Antoine Martin
Status: newassigned

Almost everything (except the map / unmap code) was backported in r8336 + r8337 (+ minor fixes and tweaks in r8339, r8340, r8341 + r8342).

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)
Last edited 5 years ago by Antoine Martin (previous) (diff)

Changed 5 years ago by Antoine Martin

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

comment:11 Changed 5 years ago by Antoine Martin

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?

comment:12 Changed 5 years ago by Antoine Martin

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.

comment:13 Changed 5 years ago by Antoine Martin

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

comment:14 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

comment:15 Changed 4 years ago by John1221

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

comment:16 Changed 3 years ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.