search

streamlink / streamlink-twitch-gui

A multi platform Twitch.tv browser for Streamlink
https://streamlink.github.io/streamlink-twitch-gui/
MIT License
2.69k stars 203 forks source link

Window decorations are shown on X11 and Gnome Wayland #1008

Closed ChrisLauinger77 closed 6 months ago

ChrisLauinger77 commented 6 months ago

Checklist

Streamlink Twitch GUI version

2.5.1

Streamlink version

6.7.3

Operating system, environment and configuration details

Debian testing / wayland https://gist.github.com/ChrisLauinger77/ac3f8a7cf89c1499688617bbad1d0cdb

Description

I updated to 2.5.1 and now I see window decorations from OS and then I have also the header from the regular UI. Resulting in 2 times the header and also the minimize maximize and close buttons are twice there: Bildschirmfoto vom 2024-05-11 20-25-25

Debug log

No response

bastimeyer commented 6 months ago

Must be a Gnome/Mutter issue (for XWayland clients). There are no window decorations on Plasma/Kwin.

Try launching with --ozone-platform=wayland.

Porkepix commented 6 months ago

I was going to open the same issue. Also note that along this issue, the + button only reduce the size of the window but it doesn't do anything anymore if it's not maximized to set it to maximized again.

I tried to launch with --ozone-platform=wayland and indeed, the window decoration isn't there anymore. However the + button in this case does absolutely nothing and is completely broken, not half-working like in the first case. The - button also act very strangely: streamlink-twitch-gui only shows a twitch icon on the top-left corner when it's supposed to be foreground and becomes in a weird state where it's not possible to restore it anymore, you can only obtain that strange icon.

bastimeyer commented 6 months ago

Decided to take the time and set up a fresh Arch VM with gnome-desktop, sway and hyprland.

So yeah, like I've said, this is a Gnome issue with XWayland clients. NW.js 0.82 defaults to using Chromium's xorg ozone platform implementation on Wayland. If you force the wayland ozone platform implementation via --ozone-platform=wayland, the window decorations are gone. https://wiki.archlinux.org/title/Chromium#Native_Wayland_support

I don't really want to add an additional wrapper around the executable which checks for a wayland session and then adds the launch argument. Not even sure if every user would want this.

This is a Gnome/Mutter issue which will need to get fixed there. Other Chromium-based applications using the same Chromium version should also be affected by this on Gnome.

If you're having issues with the maximize/unmaximize button (the "+"), then this is caused by the window manager and the app's last window position/state which the app tries to restore upon launch. This happens when switching between XWayland and Wayland run modes. Just toggle the maximized state by double-clicking the app's header bar where you can also drag.

bastimeyer commented 6 months ago

Looks like a reverse-issue of this due to the app running on XWayland by default:

Also a good read about why you shouldn't use Gnome...

I don't know if newer versions of Chromium will fix this by defaulting to Wayland (probably not), but I currently can't use anything newer than NW.js 0.82 with Chromium 119 due to #1005. 2.5.1 downgraded from NW.js 0.87 with Chromium 124 because of this.

As said, I don't really want to add a wrapper launch script that sets the --ozone-platform=wayland Chromium launch argument when the WAYLAND_DISPLAY env var is set.

The AUR PKGBUILD(s) already add a wrapper to /usr/bin/, which is where this should be added: https://github.com/streamlink/streamlink-twitch-gui-aur/blob/1067dbd4d43763c647e1e6e45c09ebe3d836eeb7/PKGBUILD#L46-L50

The AppImage currently simply symlinks the executable though, so this would require a change and another release: https://github.com/streamlink/streamlink-twitch-gui/blob/f3eda33b0c94ba684cb450351aa0085df1b638af/build/resources/appimage/build.sh#L116-L118

But if I'm already going to make changes to the AppImage and publish a new release, then I can also add a wrapper launch script to the tarballs.

Overall, this is still a Gnome issue, so I will have to think about whether all this effort is worth it, just because of Gnome.

I knew that bumping the NW.js version would lead to all these issues, because Chromium has been really bad lately... There was no choice though because of #1004.

Porkepix commented 6 months ago

Decided to take the time and set up a fresh Arch VM with gnome-desktop, sway and hyprland.

I'm interested by the fact you setup an hyprland environment. Another computer I have is currently running with it and encountered usability issues with streamlink-twitch-gui 2.5.X, leading me to downgrade to 2.4 for now, until I took some time digging it to report the issue. So I'd be curious if you encountered it too. It was some fullscreen issues and interactions between streamlink GUI and mpv regressing and acting very differently than it did with 2.4, and this is an issue I encountered on hyprland only, not Gnome. Note that 2.5.0 also had the issue, so with nwjs 0.87.

And yeah, issues around Gnome and CSD are quite known, I've already encountered them in the past for example with Alacritty among other cases.

bastimeyer commented 6 months ago

I don't use Hyprland or any tiling window managers. I just wanted to check NW.js's/Chromium's behavior on wlroots based compositors. Streamlink Twitch GUI is not responsible for launching the player. Streamlink is, which itself is launched by the Twitch GUI (obviously). This is all offtopic, btw...

cadbusca commented 6 months ago

I'm having similar issues here with the '-' and '+' buttons. Sometimes they work, mostly of the times they don't (clicking on them have no effect). I'm using KDE and X11. The issue start happening after clicking a few times on those buttons. Double-clicking the app's header bar does not fix the issue.

Streamlink Twitch GUI version 2.5.1

This issue does not happen on v2.4.1

ChrisLauinger77 commented 6 months ago

So the tool was updated and now used wayland rather then x11 which leads to the behaviour on gnome (before xwayland was used it seems).

So there are 2 solutuions: 1 - custom .desktop file where "--ozone-platform=wayland" is added to the call 2 - custom start shell script ( I attach the one I use - it checks for $XDG_SESSION_TYPE and only then adds "--ozone-platform=wayland" start.zip I use the start script solution and my .desktop file just calls this. It will survive the update of the tool and it looks again like this for me: grafik I am happy. The "-" and "+" buttons work fine for me. People might wanna file a different issue for that. Should we keep this open or close it ? As of me it could be closed ...

ChrisLauinger77 commented 6 months ago

I just found the "add-menuitem.sh" :) I added the checks for gnome/wayland there ... add-menuitem.zip

bastimeyer commented 6 months ago

So the tool was updated and now used wayland rather then x11 which leads to the behaviour on gnome (before xwayland was used it seems).

No, this is not what I said.

NW.js got bumped from 0.78.1 (Chromium 115) to 0.87.0 (Chromium 124) and then downgraded back to 0.82.0 (Chromium 119). When using a wayland compositor, Chromium still defaults to their xorg ozone platform implementation, even in the latest version, which means it's run on top of XWayland. This hasn't changed, and it affects regular Chromium, as well as anything based off of it, namely NW.js, Electron, or Chrome embedded framework apps. This behavior can be overridden via the mentioned launch argument, --ozone-platform=wayland.

Run xlsclients on your system to see any XWayland applications.

NW.js properly initializes its main window with the following X11 property:

_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0

which tells the compositor to remove any window decorations. You can check this via xprop and even change the property via

xprop -f _MOTIF_WM_HINTS 32c -set _MOTIF_WM_HINTS "0x2, 0x0, 0x0, 0x0, 0x0"

On Gnome/Mutter however, the value is set to

_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0

which enables window decorations. It also sets the following Mutter-specific property:

_MUTTER_NEEDS_FRAME(CARDINAL) = 1

This does only occur on Gnome when using NW.js 0.81.0 or above (Chromium 118). NW.js 0.80.0 (Chromium 117) still has the right X11 properties and thus no window decorations.

I don't see any changes in the NW.js/Chromium source code in regards to the _MOTIF_WM_HINTS X11 property though:

Considering that any other Wayland compositor doesn't have this issue and only Mutter (Gnome) is affected, this looks very much like a Gnome issue. I don't know though what exactly has changes between those two Chromium versions, but it's unrelated to the _MOTIF_WM_HINTS X11 property which it sets, as shown in the links above. It's probably an override of Mutter itself via some other window properties it checks. I don't know.

custom start shell script ( I attach the one I use

Why are you using this wrapper launch script? This has been removed 5 year ago in v1.7.0: 0841a5d01c8216e17f86f1a1e95b8ff72669f518

ChrisLauinger77 commented 6 months ago

Because I executed the add-menu-item.sh 5 years ago. And then forgot about it. But I changed the add-menu-item.shas posted earlier meanwhile.

bastimeyer commented 6 months ago

Apparently this issue affects all X11 compositors.

bastimeyer commented 6 months ago

So I decided to downgrade NW.js on Linux back to 0.80.0. This build doesn't seem to have any SKIA shader compilation issues like 0.78.1, which started all this mess. Anything above 0.80.0 though, including the latest NW.js version 0.87.0, still has the window decoration issue on X11 (or XWayland on Mutter/Gnome).

0.80.0 however is broken on macOS, which got fixed in 0.81.0. So unfortunately, this meant that I had to do what I've been avoiding all these years and split up the NW.js versions per platform. These are the current versions on master right now:

Another solution could've been adding a launch wrapper script for Linux and then trying to override the _MOTIF_WM_HINTS X11 window property. This would require the xwininfo and xprop utilities, where getting the window ID would need to be run in a loop. However, since the main window is hidden at the start and there would obviously be some bad timing issues when initializing the window, I decided against this. I had implemented a similar launch wrapper script in the past where the WM_CLASS X11 window property was set, but any timing related issues were pretty much irrelevant in this case, so this was fine compared to _MOTIF_WM_HINTS. And native Wayland support was out of the question back then anyway...

I'd like to kindly ask everyone reading this to build from master and give this a quick test, even on macOS or Windows.

I've double-checked all my VMs, X11, Wayland (native and XWayland), Windows 10 and macOS 13, as well as my notebook with an Intel iGPU, but these recent NW.js issues have made me a bit paranoid because I obviously can't check everything. I want to avoid having to publish another release after this next one.

See https://github.com/streamlink/streamlink-twitch-gui/blob/master/CONTRIBUTING.md#developing-and-building or the streamlink-twitch-gui-git PKGBUILD for Arch users.

So what does this mean for the future?

As I've said here when I bumped NW.js from 0.78.1 to 0.87.0 in v2.5.0, the NW.js project is pretty much dead. It's been a dead end for ages, unfortunately, which is bad considering the recent issues.

When I started the "Livestreamer Twitch GUI" project in 2013, NW.js (or rather "node-webkit" back then) was the first application which bundled NodeJS and Chromium, which allowed JS-based GUI apps to be built for the first time. The project was sponsored by Intel back then.

During these early years though, one of the co-devs left node-webkit and started the ElectronJS project, leaving Roger Wang, the original author. Node-webkit became less and less popular, with Roger Wang pretty much maintaining this alone, and in 2018 the project lost Intel's sponsorship. If you take a look at their issue tracker, you can see that there's not much activity nowadays. The changelogs also only list bumps of Chromium and NodeJS, with some bare bugfixing. I don't blame anyone here, but this is the result of Electron having become the "industry standard" of writing NodeJS-based GUI apps pretty early on while being backed by GitHub/MS for their "Atom" project (which has been sunset in 2022).

I don't know how feasible it is migrating from NW.js to Electron. I've been thinking about this since at least 2016 already because of all these NW.js packaging issues on Linux distros, but even then it would've been a huge task. And considering that Streamlink Twitch GUI has been in maintenance mode (instead of active development mode) for the past couple of years due to me not having much motivation anymore to work on it because of all these Twitch API restrictions and other tech dead-ends like EmberJS and co, this makes it even worse, because transitioning now is even more effort.

So yeah, I don't know how long this can be kept alive. As you can see, I now have to downgrade NW.js by 7 releases because of unfixed issues. I will open another bug report on the NW.js repo later in regards to the window decorations on X11, but I doubt that this will attract any attention.

skulblakka commented 6 months ago

even on macOS or Windows.

Build the current master on Windows 10 (Intel CPU, NVIDIA GPU) and played around with it for a bit. Didn't notice any immediate issues.

Sneakpeakcss commented 6 months ago

I'd like to kindly ask everyone reading this to build from master and give this a quick test, even on macOS or Windows.

Win10 22H2

Build from current master (dc0568a) has some changes when it comes to taskbar contextmenu:

old:

2 5 1 taskbar contextmenu

new: master build

I'm not certain if this was intentional or not, but there's a bigger issue… Trying to open a stream with --launch parameter only works once, any additional launches during the same runtime do nothing. From what i remember this was an issue at some point, but was fixed around 2 years ago, and now it's back.

bastimeyer commented 6 months ago

I am aware that NW.js receives launch arguments from secondary app starts only once. I'll have a look later if downgrading can fix this for now. Btw, context menus and the like are rendered by Chromium, which I don't have any control over. This is a web/NodeJS application.

bastimeyer commented 6 months ago

Downgraded NW.js to 0.83 on Windows: 7b201ef2

Porkepix commented 6 months ago

I'd like to kindly ask everyone reading this to build from master and give this a quick test, even on macOS or Windows.

I've double-checked all my VMs, X11, Wayland (native and XWayland), Windows 10 and macOS 13, as well as my notebook with an Intel iGPU, but these recent NW.js issues have made me a bit paranoid because I obviously can't check everything. I want to avoid having to publish another release after this next one.

See master/CONTRIBUTING.md#developing-and-building or the streamlink-twitch-gui-git PKGBUILD for Arch users.

Built and run on the Gnome-running computer, I didn't noticed any problem, but it didn't run for long yet. Didn't fixed the tiling problem, but that belongs to the other issue.

Regarding the "engine/platform" (I think that's what nw.js is here?) it's running on, besides electron I know there are other projects, such as a Matrix client I use built onto Tauri, there are probably others but to be faire I've no idea of the pro and cons of those and what would be a good choice here. In the end, whether it is Electron or any other of those alternative platforms/engines, I guess the amount of work to move from nw.js to one of these is quite high, and probably unreasonable for a project you lost most of your interest in.

Sneakpeakcss commented 6 months ago

Downgraded NW.js to 0.83 on Windows: 7b201ef

Seems like now we lost the ability to drag the window. This is in such a cat and mouse state that i can only imagine the frustration and can understand the lack of motivation to deal with all of this.

bastimeyer commented 6 months ago

I didn't even notice... Downgraded back to 0.82 on Windows 5ee7ac973bddf53dd649d7de5e5284c0855178e4.

I'll open a new issue tomorrow with a list of what's broken on which version, because this has become unmanageable.

bastimeyer commented 6 months ago

I've created an NW.js version issues meta thread now. You can help extend/verify the table/list if you want.

I've fixed some other issues in regards to the window state now, so I'm quite confident with publishing a new release now, but I'd still rather wait a tiny bit more and see if there are more issues to be discovered. Please have a look at the linked issue above. Thanks.

bastimeyer commented 6 months ago

Resolved by 381a9a5cb507ed689b2127ad6afb67127582eef8 / ab45651abefddd9d39d515f184648214ba810c1b See #1015