Chromium in-page menus don't work with non-compositing window managers

aweb · 2022-07-16 21:36:30

I have a problem where certain pop-up or hover menus in web sites don't work if I'm using a non-compositing window manager. For example, the menu on travel.americanexpress.com gives this result:

screen shot

If I click on a selection, the menu just goes away and nothing happens. This happens with fvwm2, which is an old window manager, so I figured might be the problem. However, when I tried fluxbox, I got the same result. I also sometimes have problems with menus not working in zoom. All of these problems go away if I don't use a window manager (but of course then the system isn't usable). They also go away if I use mutter. However, mutter doesn't seem well suited as a stand-alone window manager--at least I can't figure out how to configure it the way I configure old-school window managers. Note that firefox still works, fortunately.

Has anyone else experienced these problems? Is there any workaround? I tried running picom, but it didn't solve the problem. My first choice would be to make chromium work with fvwm2 and/or fluxbox. Failing that, does anyone have a recommendation for a compositing window manager that doesn't feel too alien for someone who is used to editing shortcuts and lots of other configuration in plain-text files under git? I admit that mutter looks good, but I just don't want a whole desktop environment as I prefer doing most things at the command-line.

seth · 2022-07-17 06:02:41

If I open that page and click on cruises, https://www.americanexpresscruise.com/p … ook-cruise opens - I don't see how on earth that could relate to your WM, let alone a compositor (and you've already established that picom doesn't help)

I suspect some input issue, perhaps a shortcut daemon?
Because the popup hides on "unhover".

On a formal matter, please replace the oversized animated image w/ a link, the board has a 250x250 limiting rule.

karabaja4 · 2022-07-17 10:38:22

seth wrote:

I don't see how on earth that could relate to your WM, let alone a compositor (and you've already established that picom doesn't help)

It could, Chromium developers have been disregarding non-compositing setups for a while now (feelsbadman.jpg), and artifacts/unexpected behaviors on non-compositing window managers are very common when using hardware acceleration, at least in my experience.

@aweb, if that is an option, did you try disabling the hardware acceleration (running chromium with --disable-gpu)?

You could also try this trick I'm using on Openbox, running "xcompmgr -a" to enable automatic server side compositing. It doesn't actually enable real compositing, but it helps with Chromium artifacts for some reason, at least on my Nvidia/Openbox/PRIME setup.

Last edited by karabaja4 (2022-07-17 10:42:03)

seth · 2022-07-17 12:42:33

Chromium developers have been disregarding non-compositing setups

That may very well be, but

OP wrote:

All of these problems go away if I don't use a window manager

OP wrote:

I tried running picom, but it didn't solve the problem.

aweb · 2022-07-17 23:59:45

@aweb, if that is an option, did you try disabling the hardware acceleration (running chromium with --disable-gpu)?

I should have mentioned this. The `--disable-gpu` flag _used_ to be a workaround for the problem, but a couple of years ago it stopped working as well. Now, I get the problem even with the `--disable-gpu` flag. Also, I should say that the problem happens even with a completely vanilla setup with no customization. I just gave up on chromium since then, but now that fvwm has been exiled to aur, I was thinking maybe I should switch window managers.

You could also try this trick I'm using on Openbox, running "xcompmgr -a" to enable automatic server side compositing. It doesn't actually enable real compositing, but it helps with Chromium artifacts for some reason, at least on my Nvidia/Openbox/PRIME setup.

Interestingly, openbox seems to solve the problem, even without `xcompmgr -a`. I had initially picked fluxbox because it is in the arch extra repository, while openbox is only in community.

I'm fairly attached to fvwm because I've been using it for 25 years and when it works it does exactly what I want. If I invest a lot of time in learning another window manager, I'm hoping it will A) eventually let me do everything I want (and put the config under git so I get it on all my machines), and B) have a reasonable chance of working for 25 years (which possibly requires wayland compatibility?). I thought fluxbox looked more supported, but maybe I should consider openbox.

Incidentally, just a PSA for anyone else trying a bunch of window managers: After I installed gnome (to try mutter), a bunch of applications like firefox and pavucontrol started taking 25 seconds to start up. Turned out I needed to add `source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh` to my `.xinitrc` file. It took me a while to figure this out because I'd also switched to pipewire at the same time, and so had no idea that this was related to having gnome on my system.

Trilby · 2022-07-18 00:26:08

aweb wrote:

I had initially picked fluxbox because it is in the arch extra repository, while openbox is only in community.

Huh? You cant / shouldn't run without the community repo enabled.

aweb wrote:

If I invest a lot of time in learning another window manager, I'm hoping it will A) eventually let me do everything I want (and put the config under git so I get it on all my machines), and B) have a reasonable chance of working for 25 years (which possibly requires wayland compatibility?).

No X11 WM will ever have "Wayland compatibility" - that's just not a thing. Some may get a wayland compositor developed to mimic their behavior and use the same configs with minimal changes from the user's perspective (e.g., sway as a wayland alternative to i3). But I'm pretty sure this would be *far* more likely for openbox than for fluxbox - I believe the former has a much larger userbase, and there is (or has been) at least one wayland clone of openbox already. [1]

aweb wrote:

I needed to add `source /etc/X11/xinit/xinitrc.d/50-systemd-user.sh` to my `.xinitrc` file. It took me a while to figure this out because I didn't read the wiki

Fixed that for you.

1. EDIT: actually there are at least two. Labwc is the one I had ran into before and appears to be doing quite well. There is always a "waybox" which is a similar project currently labeled a WIP despite having been around for a long time.

Last edited by Trilby (2022-07-18 00:29:42)

aweb · 2022-07-18 01:29:34

Trilby wrote:

aweb wrote:
I had initially picked fluxbox because it is in the arch extra repository, while openbox is only in community.
Huh? You cant / shouldn't run without the community repo enabled.

I have the community repo enabled. I'm just operating under the belief that packages in extra are way less likely to get banished to the AUR than packages in extra. So if I want to pick a package that's going to be supported for a while, all else equal extra is better than community.

aweb wrote:

II didn't read the wiki

Sorry, which wiki, can you provide a link? I'd still like to understand the problem better, because gnome obvoiusly did something to mess up a setup that was working perfectly. And since quickly decided I didn't want to use gnome but was trying to use wireplumber, I was primarily trying to bisect the changes to my dot-files and looking at wireplumber-related things. Whatever gtk is doing is quite impolite--you shouldn't impose a 25-second delay on people without giving them some sort of warning about how to fix the problem. The worst thing is that the delay was in epoll, so strace was useless, because whatever file descriptor it usually waits for just wasn't there in the event list--presumably a missing connection to dbus?

Trilby · 2022-07-18 01:47:26

aweb wrote:

I'm just operating under the belief that packages in extra are way less likely to get banished to the AUR than packages in extra.

According the pkgstats, openbox has roughly five times as many users as fluxbox. I actually expected it to be a larger margin (and I somewhat suspect that users of less common software might be overrepresented in pkgstats).

aweb wrote:

Sorry, which wiki...

The xinit page.

seth · 2022-07-18 05:24:03

seth wrote:

I suspect some input issue, perhaps a shortcut daemon?

Or maybe the button/replay of the WM itself.
What happens if you "export GDK_CORE_DEVICE_EVENTS=1" to the session or at least chromium?

karabaja4 · 2022-07-18 11:18:17

aweb wrote:

I'm fairly attached to fvwm because I've been using it for 25 years and when it works it does exactly what I want. If I invest a lot of time in learning another window manager, I'm hoping it will A) eventually let me do everything I want (and put the config under git so I get it on all my machines), and B) have a reasonable chance of working for 25 years (which possibly requires wayland compatibility?).

Does "xcompmgr -a" help with Chromium any way in fvwm2? (remember to restart Chromium after executing xcompmgr)

Arch Linux

#1 2022-07-16 21:36:30

Chromium in-page menus don't work with non-compositing window managers

#2 2022-07-17 06:02:41

Re: Chromium in-page menus don't work with non-compositing window managers

#3 2022-07-17 10:38:22

Re: Chromium in-page menus don't work with non-compositing window managers

#4 2022-07-17 12:42:33

Re: Chromium in-page menus don't work with non-compositing window managers

#5 2022-07-17 23:59:45

Re: Chromium in-page menus don't work with non-compositing window managers

#6 2022-07-18 00:26:08

Re: Chromium in-page menus don't work with non-compositing window managers

#7 2022-07-18 01:29:34

Re: Chromium in-page menus don't work with non-compositing window managers

#8 2022-07-18 01:47:26

Re: Chromium in-page menus don't work with non-compositing window managers

#9 2022-07-18 05:24:03

Re: Chromium in-page menus don't work with non-compositing window managers

#10 2022-07-18 11:18:17

Re: Chromium in-page menus don't work with non-compositing window managers

Board footer