Waybar freezes upon activation of group drawers

[hrdl-github]

Waybar v0.10.0 and 2c927de on sway 1.9 with GTK 3.24.41. Config:

{
  "modules-left": ["group/hardware"],
  "group/hardware": {
    "orientation": "inherit",
    "modules": ["cpu", "memory"],
    "drawer": {},
  },
}

Hovering over the group usually causes waybar to freeze and produce high CPU load. I noticed that Group::handleMouseHover gets flooded with GDK_{ENTER,LEAVE}_NOTIFY events. I don't see any unusual wayland events. My gtk3 distribution wasn't compiled with G_ENABLE_DEBUG, so I didn't check that.

[hrdl-github]

The layout looks like this:

Gtk::Box box
- Gtk::Widget widget1
- Gtk:Revealer revealer
  - Gtk::Box revealer_box
    - Gtk::Widget widget2
    - Gtk::Widget widget3

At the moment the hover handler is added to

1. the Gtk::Revealer revealer:

   Waybar/src/group.cpp

   Line 82 in 2c927de

   addHoverHandlerTo(revealer);

2. the first widget, which is always visible, in box and all the other widgets in revealer_box:

   Waybar/src/group.cpp

   Lines 117 to 118 in 2c927de

   	// Necessary because of GTK's hitbox detection
   	addHoverHandlerTo(widget);

This can break in a number of ways. Ultimately leaving one widget or the revealer just to enter another widget should not trigger a state change of the revealer. Intuitively these should be handled by the outer box, but according to 05b97e9 by @Syndelis there's an issue with GTK's hitbox detection. Any idea what is appropriate here?

[Syndelis]

I recommend tweaking your CSS to make the gaps between group elements smaller, and/or making the elements themselves bigger and see if it resolves the issue

[hrdl-github]

I tested this using both the default and an empty style.css file. Setting the padding explicitly to zero doesn't help either or increasing the size of the elements by adding some text doesn't help either.

[Syndelis]

Try with my configs and tell me how it goes

waybar.tar.gz

[hrdl-github]

When leaving any of the groups upwards waybar freezes and I have to restart it. Leaving them sideways closes them correctly, assuming the bar is on the left.

[Syndelis]

Leaving them sideways closes them correctly, assuming the bar is on the left

Assuming the bar is vertical (as is the one from my config) what do you mean by "leaving them sideways"?

[hrdl-github]

Maybe this clarifies my explanation:

recording.mp4

Leaving the first widget to the right fires a single LEAVE event and closes the revealer. When entering the revealer the handler gets flooded with ENTER and LEAVE events and blocks.

Commenting out

Waybar/src/group.cpp

Line 92 in 2c927de

revealer.set_reveal_child(false);

prevents the event flood and makes things a bit more interpretable: leaving the first widget and entering the revealer fires a LEAVE event followed by three (for >= 1 widgets in the drawer) ENTER events. Moving further a LEAVE and an ENTER event is trigger for each transition from widget to widget within the revealer. Leaving the revealer fires three LEAVE events. Beside set_reveal_child(false) breaking things for some reason this is still one more ENTER and LEAVE event than I'd expect.

[hrdl-github]

I've fixed the hover issue, but introduced some other event-related issues. I'm not very familiar with GTK3 and was mostly looking into this out of curiosity, so I'd appreciate any insights on this.

[hrdl-github]

I am still experiencing an issue with 0.10.3 when entering/leaving the group parallel to the bar. Config:

    "group/group-upower": {
      "orientation": "inherit",
      "drawer": {},
      "modules": [
        "battery",
        "upower",
      ],
    },

waybar-groups.mp4

Should I open a new issue for this, @Alexays ? I haven't checked whether anything of #3044 could be reused.

[haug1]

I probably caused this issue with too aggressive refactoring starting in: #3201.
Sorry. We earned hover styling for whole groups, but regressed a little bit in terms of "hover hitbox", I guess I can call it? Is it fair to say that after the update it is less aesthetically pleasing how the "hitbox" triggers, but not a "critical" issue like before where you could consistently stuck it?

[hrdl-github]

Absolutely. I haven't been able to trigger any "critical" issues.

[haug1]

Can you try adding this config in your group, see if that makes things better for you?

    "drawer": {
      "transition-duration": 500,
    },

[hrdl-github]

It doesn't. I've never noticed any difference when setting transition-duration.

[haug1]

Can you share your CSS also? Here's how it looks on my PC:

So I don't know.

[hrdl-github]

This time removing any padding and margin from the group seems to solve the high-frequency toggle issue. I haven't been able to trigger the transition animation yet.

I'd be fine with closing this issue.

[haug1]

Cool. I have a feeling what you're experiencing with the glitchy looking hitbox behavior in your latest gif is native to GTK, maybe GTK3 specifically, I have no idea, but I have an idea about frontend frameworks and this looks familiar. Maybe because a combination of border radius, no smoothing animation and maybe also some hover styling which increase width of GUI components is causing the issue. As for why smoothing animation is not working for you it may be some issue related to waybar, but I haven't seen it yet myself.

[haug1]

And I agree that closing the issue is fine from my current understanding. Especially since it can be confusing that the original post is not the issue anymore. Maybe a new issue is warranted.

[TheRealGramdalf]

Just thought I'd tack this on here as there seem to be several similar issues (please let me know if I should split it out)

This may just be an issue with my lack of CSS knowledge, but I can't seem to find how I should go about styling my drawer. My power menu (which is in many ways similar to the example on the wiki) is in it's own sub group - essentially some margin and border-radius to make it appear like a separate group (akin to modules-<left|right|center>). When I hover over it, the drawer expands to one side, leaving the border-radius of the group leader in place (for reference, see the attached video).

To my understanding this could be fixed by giving the group leader an additional styling class when the drawer is active (removing the border radius and/or syncing the animation with the group children), which is discussed here in some places.

For reference, my waybar config & css can be found here (beware, here be reproducible dragons): https://github.com/TheRealGramdalf/nixos/blob/a4ae9897abe0e734dfe18b62fd076de8bdd94de1/config/users/gramdalf/hypr/waybar.nix#L133-L157

waybar.mp4

[haug1]

@TheRealGramdalf See my reply here for a workaround for this problem in 0.10.3. (Notice especially how I set the border-radius on hover.) It will not be a perfect workaround as mentioned in that post.

Btw, this new approach will probably stop working soon when group hover is removed/reverted, I'm expecting that to happen, but don't know anything. It's just causing too many issues unfortunately.

[hrdl-github]

I haven't been able to trigger the transition animation yet.

Mystery solved. I forgot that I use the following to reduce the amount of animations encountered in librewolf/firefox.

> gsettings get org.gnome.desktop.interface enable-animations
false

With the styling posted above I'm still observing the same issue, just less erratic.

[hrdl-github]

Closing this in favour of #3243. Using @haug1's snippet referenced above as inspiration I'm using the following. Border radius and animation smoothing don't seem to cause any issues in this case, but padding and margin should only be added to #group > * > * elements and not to #group elements.

#group-upower {
  border-radius: 15px;
  background-color: alpha(#747474, 0.3);
}
#group-upower > * > * {
  padding: 0 4px;
}