Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streamlink-twitch-GUI stuck on floating mode on hyprland, maybe any tiling WM since 2.5.x #1012

Closed
4 tasks done
Porkepix opened this issue May 15, 2024 · 6 comments
Closed
4 tasks done

Comments

@Porkepix
Copy link

Porkepix commented May 15, 2024

Checklist

Streamlink Twitch GUI version

2.5.1

Streamlink version

6.7.4

Operating system, environment and configuration details

ArchLinux, Hyprland

Description

Since 2.5.X, probably due to nw.js changes, streamlink-twitch-GUI only offers floating or full screen modes at least on Hyprland, maybe also other compositors such as Sway.
That means it gets stuck on foreground in both cases, unless we set another tile as fullscreen to go on top of it. In the end it completely breaks the tiling.
This is a regression from 2.4.x which had no problems (I did a downgrade to check issue is gone on 2.4.x). Gnome gets no issue around this (which makes sense, no tiling by default).

Note that the problem is when it's running with the default parameters, ie. on XWayland.
When forcing the use of Wayland with --ozone-platform=wayland, that issue is gone, but some other issues arise such as the default tray icon getting its own tile window.

Note that Hyprland maintener suggested it could be an issue with window requested max size and suggested to try to override it from Hyprland's side, but it didn't fixed anything. (If the max size is smaller than what the tile size would be, then Hyprland don't tile it).

Debug log

No relevant logs, but here are some n case it might show something interesting for some issues with some visible warnings/errors:

[64168:64168:0515/112954.786929:ERROR:policy_logger.cc(157)] :components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(163) Cloud management controller initialization aborted as CBCM is not enabled.
[0515/112954.805744:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[debug][Application]
Parameters
{
    "_": [],
    "tray": false,
    "hide": false,
    "hidden": false,
    "max": false,
    "maximize": false,
    "maximized": false,
    "min": false,
    "minimize": false,
    "minimized": false,
    "reset-window": false,
    "versioncheck": false,
    "version-check": false,
    "logfile": true,
    "loglevel": "debug",
    "l": "debug",
    "theme": "",
    "launch": "",
    "goto": ""
}
[64214:64222:0515/112955.253034:ERROR:cert_verify_proc_builtin.cc(621)] No net_fetcher for performing AIA chasing.
[64214:64222:0515/112956.135863:ERROR:cert_verify_proc_builtin.cc(621)] No net_fetcher for performing AIA chasing.
[64214:64222:0515/112959.865820:ERROR:cert_verify_proc_builtin.cc(621)] No net_fetcher for performing AIA chasing.
[64214:64222:0515/113007.962638:ERROR:cert_verify_proc_builtin.cc(621)] No net_fetcher for performing AIA chasing.
[64211:64211:0515/113015.082268:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
@bastimeyer
Copy link
Member

Did you read #1008 (comment) ?
NW.js on Linux has been downgraded to 0.80 on master. STG v2.5.1 with NW.js 0.82 is irrelevant. You didn't even bother to try building from master.

Also give me a break, man... There are tons of other issues with NW.js/Chromium releases, as you can see in the recent releases, the linked issue and the recent changes on master. Tiling window managers are such an edge case, it's barely even relevant.

@Porkepix
Copy link
Author

Porkepix commented May 15, 2024

Did you read #1008 (comment) ? NW.js on Linux has been downgraded to 0.80 on master. STG v2.5.1 with NW.js 0.82 is irrelevant. You didn't even bother to try building from master.

When I read it, it maybe didn't even have a third of the content the message currently have. Especially, the request to test latest wasn't there at that time. There was the part about downgrading nw.js and splitting platform though, which is why I checked if there was a new release yesterday and this morning before opening this.
I'll try to get a build from AUR's package, although on the computer running Gnome building such things might be quite long for me.

Also give me a break, man... There are tons of other issues with NW.js/Chromium releases, as you can see in the recent releases, the linked issue and the recent changes on master. Tiling window managers are such an edge case, it's barely even relevant.

Don't get me wrong, you don't owe anyone anything; don't feel compelled to fix those or act immediately, a downgrade is always possible by us users for such situations (which is what I did on the computer running Hyprland: I downgraded to 2.4.x, because usability is a pain with this issue).
But I don't think keeping issues unreported is a good solution either, especially when as a user I don't know well enough interactions between the project and nw.js to know when the project can do something on its own, and when I should just report it straight to nw.js without knowing even a bit about how does it work.

@Porkepix
Copy link
Author

Porkepix commented May 15, 2024

So, I did the test and issue is still around when built from master on nw.js 0.80.

EDIT: As for the tray icon issue, it's probably something that should be reported upstream on nw.js tracker, but is it even worth it if nobody works on this anymore?

@Porkepix
Copy link
Author

So, after playing with git bisect, it found out the culprit commit was fa0d9a6.
But I've already shown in #1015 (comment) that I could not reproduce the issue with older code but newer nw.js. In the end I could see that this commit was also changing the --disable-features=nw2 flag by removing it.

I concentrated investigations on this and could confirm several things:

  • If I remove the flag on release v2.4.1, I reproduce the issue;
  • If I re-add this flag on latest commit on master, it fixes the issue;

In the end, I can't tell what nw2 is changing nor why was it disabled and now reenabled, but it's the cause of the issue here, not the nw.js version.

@bastimeyer
Copy link
Member

NW2 is a re-implementation of NW.js's JS bindings. NW1 has been removed (or stopped working) in 0.85, hence the removal in this commit. This is also the reason why the exit confirmation dialog started working again, because the app's close event is broken in NW1. However, in NW2, the app-window's blur event is broken. This has been a pick-your-poison situation for me since at least one and a half years. The issue has been reported by me a long time ago with a couple of bumps, but without any responses.

Considering that the Linux and Windows builds are now stuck on 0.80 and 0.82 respectively, I can have a look at disabling NW2 again.

@bastimeyer
Copy link
Member

Resolved by 381a9a5 / ab45651
See #1015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants