Electron: titlebars are not hidden with ozone wayland backend

[HeroBrine1st]

Describe the bug

Titlebar hiding does not work with electron apps on wayland (xwayland works). Not one app, examples: official discord package, vesktop, element-desktop, spotify.

I have a minimal VM to troubleshoot that problem. See the screenshot: vesktop in VM has titlebar while QEMU window does not (the same with firefox). QEMU window is a wayland window, I confirmed it with xprop (anyway firefox is 100% a wayland window). Configurations of unite within VM and on host are the same, I literally copied the config then stripped it.

Also functionality of electron titlebar is damaged: RMB on it does not show popup menu at all (even when unmaximized), while clicking on status bar works as well as alt-space. Dragging works as with firefox (no cursor change with both), indicating that titlebar is CSD and not just within a window's framebuffer.

To be clear, this issue was seen on Arch Linux with GNOME 45, but now I'm on NixOS so I'm going with that.

AFAIK, electron draws titlebar using libgtk, so it uses gtk.css as, for example, firefox and qemu.

To Reproduce
Steps to reproduce the behavior:

1. Configure unite to hide titlebars:

$ dconf dump /org/gnome/shell/extensions/unite/
[/]
autofocus-windows=false
extend-left-box=false
greyscale-tray-icons=false
hide-app-menu-icon=false
hide-window-titlebars='maximized'
notifications-position='center'
show-appmenu-button=true
show-legacy-tray=true
use-activities-text=false
window-buttons-placement='right'

2. Launch electron app via wayland and maximize it (vesktop, for example)
3. See that titlebar is still rendered

Also, there's other, purely functional™ way to replicate the issue. I have a minimal VM that closely represents my case by replicating affected parts of my system, using vesktop as an example: nixos-rebuild build-vm --flake github:HeroBrine1st/flake#unite-shell-debug-vm. Probably this command works only on nixos systems, not sure. I can't share disk image as it shares /nix/store with host system, sorry.

Then launch VM and make sure that it creates disk image from scratch (otherwise home-manager goes mad). User has password p4$$w0rd and environment is already configured by home-manager. Just launch gnome-terminal, write NIXOS_OZONE_WL=1 vesktop, setup vesktop (no login required), maximize discord login window and see that titlebar is not hidden.

Expected behavior

Titlebar is hidden with electron apps as with firefox and QEMU.

Screenshots

Environment (please complete the following information):

• OS: NixOS 24.11.20240712.7e7c39e (Vicuna) x86_64
• GNOME Shell version: 46.3.1
• Unite version 78 (I see no fix in 79, also 79 probably didn't land on nixpkgs yet)

Logs
Didn't set up clipboard sharing, please see images:

P.s. I definitely had vesktop maximized despite being yet another reset of this VM

Additional context

I'm trying to debug this problem from the 535 nvidia driver release and VERY VERY VERY frustrated. With 555 driver being in release, I tried to go wayland again and got here (again). Problem is not unique to nvidia though, as I replicated it in a VM and also write this text from a laptop with amd gpu, where I tried a last attempt to debug that.

My current hypotesis is "electron ignores gtk.css", but this prompt is ungoogleable.

Please, could you tell me a way to properly debug this bug to write a proper bug report? ("debug this bug" lol, no pun intended)

The following is my frustration. TL;DR everyone fixed it, I can't.

I see many issues about this problem. Those two are just listed as closed without having any information:

• Gnome 46 wayland does not hide tittle bar #366 - closed by issuer. First they somehow fixed it with wlprop (how on earth they did it?? it does not work with gnome at all), then again by reinstall (please tell me why on linux everyone fix their problems windows-style reinstalling while proper approaches like using package manager (pacman and nixos in my case) do not work at all), and then closed it.
  And yes, I tried installing wlprop, no effect.
• Doesn't work on Gnome 46.1 #365 the same: reinstall and it works.

Please tell me how to reinstall something on NixOS or Arch in a way that it fixes something (package managers fix those problems as a class). (sarcasm obviously)

Okay, probably wlprop is really required. I found this reddit post, where TS found wayland's xprop for GNOME or sway but didn't tell what exactly. Subsequent googling didn't get any results, frustrating me again. Not to mention that wlprop isn't even mentioned in source code.

Other issues:

• Firefox 121 title bar is not hidden #361 is not the case: firefox and QEMU are hiding their titlebars properly
• Add support for Qt client side window decorations (CSD) #167 looks like this problem but specific to Qt.

Also I thought it is a problem of firejail (likely no access to css, like here #303), but minimal VM does not include firejail so it is false.

There are other cases of frustration which I don't include here because I'm hungry (write-proofread-repeat-ing this text for ~1 hour).

Sorry for this longread, but I'm really frustrated. I tried to do as much effort as currently possible in this bug report.

[korason7117]

see this comment

[HeroBrine1st]

According to my previous knowledge, and also to nix-store -q --tree, electron depends on gtk:

/nix/store/2ayryq3clabcblbj2ipbvcrp31h9lknx-electron-33.0.0
├───/nix/store/2dgqnmvrskxap0f315h13pvpyq7hr1s5-gtk4-4.14.5
...

It is also a dependency on Arch Linux, examples: AUR official repository (gtk3 but anyway gtk).

I don't know how to properly check if it is a real gtk4 titlebar, but I have heard that electron gave up and depends on gtk4 exactly to render that titlebar (and I have no other explanations). That's why I wrote that issue, that's why I'm frustrated - it should work but it does not. And I can't even confirm or deny that it is an upstream issue,

Also, plain electron (without any app) is also affected. It's not a surprise though.

[HeroBrine1st]

Also I found related change in electron: electron/electron#29618

According to messages there, at least some themes work so gtk.css should too.

A bit suspicious that there's no gtk includes (and also dependency on gtk was already there - pardon my delusion).

[jonian]

Hi @HeroBrine1st! You can check with xprop if an app is running in X11 mode. Open a terminal and run xprop and then click on a window. Example output from discord on arch linux. If a window is not running in X11 mode, you will not be able to click it.

➜ xprop

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 37, 0
_GTK_EDGE_CONSTRAINTS(CARDINAL) = 170
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FOCUSED
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_MUTTER_NEEDS_FRAME(CARDINAL) = 1

# ... more output here ...

Another way to check is to use GTK debug using the command below.

GTK_DEBUG=interactive discord

Since GNOME 44, X11 apps on wayland are handled by mutter-x11-frames (more info at #357 (comment)), which means that all Xwayland apps now use the CSS approach to hide their titlebars and xprop is not used at all, since it has no effect.

Other related issues to mutter frames are #357 and #369.

Issues reported on gnome gitlab related to mutter frames and xprop.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2912
https://gitlab.gnome.org/GNOME/mutter/-/issues/2792

[jonian]

@HeroBrine1st since all apps on wayland (native or xwayland) use CSS to remove window decorations, your issue with electron apps seems to be that they don't use the CSS injected by the extension in gtk-4.0/gtk.css and gtk-3.0/gtk.css.

[HeroBrine1st]

Yes, that's also my hypotesis that they don't read those files. But..

Playing around with GTK_DEBUG=interactive under wayland, I have found that pasting whole gtk.css (either from gtk-4.0 or gtk-3.0) have no effect, like rules do not apply. But something strange happens, when I try to edit them and try different variants.

For example, this:

.maximized .titlebar.default-decoration {
  margin: -200px 0 0;
  opacity: 0;
}

Does not work at all, despite titlebar having default-decoration class too. Attaching object hierarchy for reference:

But something like that:

.maximized .titlebar {
  margin: -200px 0 0;
  opacity: 0;
}

Actually triggers and properties are applied, but margin is ignored. Also there are very strange artifacts when titlebar is transparent, but it is not visible on screenshots (nvidia bugs? idk). Yes, titlebar here is transparent, you can actually see it if you open this image in gThumb.

Then I did this:

 herobrine1st  ~/.config/gtk-3.0  cat gtk.css
.maximized .titlebar {
  margin: -200px 0 0;
  opacity: 0;
}

And then NIXOS_OZONE_WL=1 vesktop

And those artifacts (i.e. transparent titlebar) are reproduced. It confirms that our initial hypothesis "gtk.css is not loaded" is invalid. And my "research" shows strange behavior of CSS rules (i.e. they don't match while they should)

So, gtk.css is read, loaded, and there's an issue with css rules. I guess.

UPD: electron --ozone-platform-hint=auto - the same artifacts, so gtk.css is also loaded in base electron.

[HeroBrine1st]

Also, more easily reproducable examples that it reads gtk.css:

Contents of ~/.config/gtk-3.0/gtk.css:

/* UNITE windowDecorations */
/*@import url('/run/current-system/sw/share/gnome-shell/extensions/[email protected]/styles/gtk3/buttons-right/maximized.css');*/
/* windowDecorations UNITE */

.titlebar {
  color: rgba(1,0,0,1);
}

Btw, no matter what I set for RGB, it is always black :-) Alpha channel works:

alpha=0

alpha=0.2

And even if I change .titlebar to .title, the behavior is the same :-)

[jonian]

Yep CSS is loaded but it seems that the CSD created by electron is not compatible with the styles the extension uses to hide the decorations. There isn't anything I can do to fix this if the CSS negative margin does not work.

Maybe you can open an issue on electron about it. You only solution for now is to use the X11 ozone backend.

[HeroBrine1st]

Also --disable-features=WaylandWindowDecorations flag is another "solution". It removes titlebar when maximised at the cost of removing titlebar when not maximised. Looks good for me :-)

^{(and yes, that was floating on surface. I actually used that on arch linux when WaylandWindowDecorations was not enabled-by-default feature, but now I wondered whether I can disable it and I actually can)}

I'm considering writing an issue to electron, but surely not today