firefox-bin-91 No window controls and can't drag [SOLVED]

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

I have firefox-bin installed, really just for the occasional crap web site that won't work with my usual palemoon. This is all from within fluxbox-1.3.7-r4.

I just had to downgrade from www-client/firefox-bin-91.0.2 back to www-client/firefox-bin-78.13.0 due to one of the stranger things I've run into. With version 91 I have no window controls at all (for example I can only close with Alt-F4), and can't grab or drag the window with the mouse...total train wreck.

Anyone else run into this and have any clue what's up there? My opinion of the Mozilla devs literally gets lower every day.

Tom

dbtx · Tux's lil' helper Joined: 20 Jan 2020 Posts: 117

I suspect you're getting bit by FF's CSD support, somewhat like [solved] Firefox 89 (CSD) not handled by fluxbox, and I don't know how to easily force it to behave, if a way exists. I'm not sure if this can still apply to FF 91, but you might try this, from a comment on gtk3-nocsd:

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

Wow...I'm sure you're right, and yes, that title bar option was already checked.

Do the Mozilla devs (or the freedesktop.org devs for that matter) ever actually improve anything, or are they too busy breaking everything with the latest shiny object, and giving no way to fix it? Are we all supposed to confirm and use Gnome? They've all come to epitomize literally everything that's wrong with modern software development. I think the proper "fix" for this and all their issues is to put all those devs on the same ship and sink the fucking thing frankly.

I'll just stick with FF 78 for now. Thank God I use palemoon. I just hope they don't screw up thunderbird (which unfortunately I have to use, only to support everyone's horrific html emails for my work email).

Thanks for the info!
Tom

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

Wow...the issues with that are actually WAY worse then I realized too. I updated to FF 91 again to try stuff like "GTK_CSD=0 firefox-bin" etc (which didn't help) and discovered all sorts of other issues.

I have fluxbox keys configured to move windows etc and none of those work either. Worse yet, Alt-Tabbing between windows is totally broken as well, where FF is always on top...a total train wreck. What a bunch of first rate assholes.

EDIT: Out of curiosity I tried installing gtk3-nocsd from various overlays but that all failed the compile, so I gave up. The very fact that someone had to write that because those ass hats give no way to disable that says it all right?

Tom

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

OK...So I was in fact able to work around developer stupidity around this by installing the first x11-misc/gtk3-nocsd here from my local overlay:

https://gpo.zugaina.org/x11-misc/gtk3-nocsd/Dep

Note that the compile failed until I enabled the introspection USE flag for gtk+3 (which required the same use for several others). That adds the file /etc/env.d/90gtk3-nocsd which sets a few ENV variables. Just including that and trying FF 61 didn't work, but it did after I restarted X.

This BS is despicable though. Seriously.

Tom

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

You know, after reading and better understanding this mess on the gtk3-nocsd git site (https://github.com/PCMan/gtk3-nocsd) it's pretty clear that the Gtk+3 devs don't care if they break other window managers, if in fact they don't do this shit maliciously. That really doesn't surprise me though. I've seen statements made by them in the past that implied that Gtk+ itself was really only intended for Gnome.

morbid · Tux's lil' helper Joined: 05 Mar 2003 Posts: 90

Thanks! This has been driving me crazy for a while now. After the first one (91?) I found a post somewhere that said to disable gfx.webrender, which worked. But each new version of firefox changed how it could be disabled in about:config, and with v93 nothing seemed to work.... which as you eluded to, makes firefox essentially unusable. I was not wanting to move away from Fluxbox... and gtk3-nocsd certainly does work!

It would be nice if gtk3-nocsd was pulled into the official portage tree and even better if a use flag was added to the firefox ebuilds.

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

Hu · Moderator Joined: 06 Mar 2007 Posts: 21607

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

So this is interesting: Yesterday I upgraded to mail-client/thunderbird-91.3.1 which is now stable. I wanted to verify that the mozilla devs didn't do this same csd nonsense in that was well. The test got a little difficult because apparently something other than the file that gtk3-nocsd installed in /etc/env.d was setting those ENV variables. I didn't actually never figured out what was doing that.

That aside, what I discovered in the process was that, not only was thunderbird 91 not affected by this, but apparently this must have been fixed in www-client/firefox-bin-94.0.2 directly as well (which was also part of this upgrade). I've now totally unmerged gtk3-nocsd and both firefox and thunderbird have the fluxbox window decorations no problem! So nice surprise there.

Tom

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

Oh...my...God. This may be the most inexplicable thing I've ever seen in my fife. So today I mysteriously lost my fluxbox window decorations in BOTH the new thunderbird 91 AND in firefox, and had to reinstall gtk3-nocsd. Someone tell me HOW that's even remotely possible given what I did last night:

1. Unmerged gtk3-nocsd removing the library and the assignment of the above environment variables, and

2. Completely logged my user out and back in (NOT just restarting X for example).

After doing that I HAD the fluxbox window decorations in both thunderbird and firefox. Today I don't. The only explanation here would be that the csd behavior of gtk is somehow totally random or intermittent. I'm lost for words.

EDIT: Now that I'm re-reading the other related thread about this linked above (https://forums.gentoo.org/viewtopic-t-1136361-start-0-postdays-0-postorder-asc-highlight-.html) I get the impression that the behavior in Fluxbox may be what's acting randomly here. That would also explain why, even with gtk3-nocsd installed, I was occasionally loosing my fluxbox decorations. At least there's a good tip in that thread on using the fluxbox "Restart" to redraw all windows. At least that's way better than exiting entirely as I was doing. The freedesktop.org developers need to be publicly castrated.

Tom

Hu · Moderator Joined: 06 Mar 2007 Posts: 21607

Though I think this idea of client side decorations is inherently wrong, if the problem here is that Fluxbox randomly mishandles the client side decorations, both with and without gtk3-nocsd, how is that the fault of the freedesktop people? As I understand it, gtk3-nocsd is intended to be, and may actually be, sufficient to completely disable client side decorations. If it is fully disabling client side decorations, then it seems like a Fluxbox bug that it can randomly lose the Fluxbox decorations. Further, it seems like a Fluxbox inconsistency, and probably bug, that restarting Fluxbox fixes this. If the problem was that gtk3-nocsd was insufficient in disabling the decorations, I would expect that once CSDs get activated in the application, Fluxbox would be stuck with them across restarts. Instead, restarting Fluxbox resets the Fluxbox decorations, which suggests that its startup path and its runtime path do not agree about whether the affected window is or is not client-side decorated.

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

I get what you're saying, but that's really only the case if gtk3-nocsd actually is fully disabling it, and doesn't answer whether fluxbox would be working correctly if gtk itself had a proper way to totally disable it, as they should. That part I fully blame on gtk. That other thread suggests that this might be fixed in fluxbox git, but that seems extremely unclear. So you may be correct but it's still pretty hard to say. What is clear is that there SHOULD be a way to disable this bullshit that literally nobody ever wanted.

I mean how ridiculous is is that major distros like Debian need to add packages for this kludgefest, because the gtk devs are being first rate dicks?

EDIT: And never mind, who the hell other than those assholes "decided" that this bullshit CSD that nobody wants was some sort of defacto "standard" that window managers needed to deal with in the first place?

Tom

tld · Veteran Joined: 09 Dec 2003 Posts: 1816

I was able to find the following fluxbox bug. If I'm reading that correctly, it appears(?) that there's a fix for this that will be in 1.3.8:

https://sourceforge.net/p/fluxbox/bugs/1111

Pretty surprising the less than glacial pace of their releases and how old that is. In any case, this jives with that other thread that said it was fixed in fluxbox git.

Tom

marmotic · n00b Joined: 12 Mar 2022 Posts: 1

Here's what fixed it for me, same scenario, quite annoying.
I understand your annoyance tld.
I tried suggestions from links in this thread and wider but dragged my feet on gtk3-nocsd as that didn't seem to fix it properly.
I started looking deeper at the Fluxbox bug and then lost interest.

Meanwhile I applied the newly offered "dark theme" internal in Firefox and the window decorations and behaviour went back to normal?!

Also, strangely, I have three similar machines with nearly identical setups, and this window behaviour only occurred on one, the other two are fine!

qsmodo · Tux's lil' helper Joined: 20 Jun 2021 Posts: 82