Bug 483188

What kind of GPU are you using?

Does it ever happen when *not* using Chrome?

Does it still happen in a new clean user account?

Does it happen on only X11, or only Wayland, or both?

(In reply to Nate Graham from comment #1)
> What kind of GPU are you using?
> 
> Does it ever happen when *not* using Chrome?
> 
> Does it still happen in a new clean user account?
> 
> Does it happen on only X11, or only Wayland, or both?

Sorry Nate! I should have mentioned that is on Wayland, and it does happen even when not using Chrome.

In fact, I've noticed today that it primarily happens when I allow my monitor to turn off and return after a while. I don't have it set to sleep or lock, only turn the monitor off after ten minutes. Weirdly, I set it to 1 minute to test, let it turn off and tried it right after but the bug didn't appear. It may just need more time but I'm not sure yet.

(In reply to Nate Graham from comment #1)
> What kind of GPU are you using?

AMD RX6750xt

> Does it still happen in a new clean user account?

Yes it does. I should also mention that I use a dual monitor setup and this issue only occurs on my primary screen. The secondary screen is unaffected and I can use that until the main panel starts working again.

Thanks. Is it just the panel on the primary screen that's affected, or any app windows on that screen as well?

Also, is this only a visual freeze, or also a functional freeze? e.g if you use the frozen panel to launch an app, does it launch but the panel doesn't show it? Or does it not launch?

Finally, does any of this happen when you have only a single screen?

(In reply to Nate Graham from comment #4)
> Thanks. Is it just the panel on the primary screen that's affected, or any
> app windows on that screen as well?
> 
> Also, is this only a visual freeze, or also a functional freeze? e.g if you
> use the frozen panel to launch an app, does it launch but the panel doesn't
> show it? Or does it not launch?
> 
> Finally, does any of this happen when you have only a single screen?

I haven’t tested a single screen but will do that tonight.

Only the panel itself on the primary screen is affected. It is affected functionally - right clicking on it gives me the menu that would appear on a blank section (i.e option to enter edit mode, etc.). Clicking on pinned apps or the launcher does nothing.

If I grab an app, drag it to the primary screen, maximize then un-maximize it, the problem usually goes away. Otherwise it just works again after a few minutes usually. It doesn’t seem like lag.

*** Bug 483263 has been marked as a duplicate of this bug. ***

Thanks. Does it also help to restart plasmashell with `systemctl restart --user plasma-plasmashell.service`?

*** Bug 483447 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #7)
> Thanks. Does it also help to restart plasmashell with `systemctl restart
> --user plasma-plasmashell.service`?

Yes. that fixes the problem when it happens.

I also tested with a single screen by disabling the second display, waiting for idle/shut off plus some extra, then moving the mouse to wake it up. With only the primary display enabled, the *app launchers* were responding, but the notification area wasn't. The clock, back to desktop button and system tray gave no response. It resolved the same way (by messing with windows or resetting plasma shell).

Thanks a lot!

(In reply to Nate Graham from comment #10)
> Thanks a lot!

My pleasure. I should mention something I just noticed: seeing how it behaved with a single screen, the next time it happened with dual screen (just now) I tried using notification buttons. They work! So with dual screen, the app launchers become unresponsive whereas with single screen, the tray is the side that goes bad... weird.

any updates on this?

My only theory is it might be related to me not using floating or hiding panels. Could be why it only started in 6.0. Still happens here as of 6.0.3.

Definitely would be nice if you could test with and without floating, and also with and without the "opaque" setting. Basically anything you can do to narrow down the issue to a specific set of settings would be great.

(In reply to Nate Graham from comment #14)
> Definitely would be nice if you could test with and without floating, and
> also with and without the "opaque" setting. Basically anything you can do to
> narrow down the issue to a specific set of settings would be great.

Huh. Turning on Floating on the panel solves this issue for me. I've tried this a couple of times by turning on/off Floating, locking down my screen, waiting for the monitor to turn off and then unlocking the screen; when Floating is off the issue persists, but when Floating is on 
I'll leave Floating on, to see if this bug happens again.

Some extra details I've noticed when the panel is unresponsive:
When I enter "Edit mode" by right clicking on the parts of the panel that aren't frozen the Panel Settings don't appear, but that also fixes the issue.
Also If I right click the non-frozen part of the panel there's a very short period of time when the panel icons are responsive. Specifically the panel icons respond to the cursor moving over them (e.g. they light up and they show a window preview) but that lasts very shortly and I can't click on them

Fascinating. I wonder if the AMD GPU part is a red herring, and it really is about the floatingness. Or maybe they're interrelated.

I've been testing floating panels since this morning, and so far I haven't seen the issue occur. It would make sense to me if this is the issue, since I haven't heard about this issue from anyone else (except for zxq5). Most people probably just leave the floating panels on by default, and therefore never encounter a problem.

Still, its only been hours so I will report back if anything changes.

(In reply to pete from comment #17)
> I've been testing floating panels since this morning, and so far I haven't
> seen the issue occur. It would make sense to me if this is the issue, since
> I haven't heard about this issue from anyone else (except for zxq5). Most
> people probably just leave the floating panels on by default, and therefore
> never encounter a problem.
> 
> Still, its only been hours so I will report back if anything changes.

Can confirm the issue is happening for non-floating panels. I'll try setting them to floating mode and see if that solves my issue, thanks

(In reply to zxq5 from comment #18)
> (In reply to pete from comment #17)
> > I've been testing floating panels since this morning, and so far I haven't
> > seen the issue occur. It would make sense to me if this is the issue, since
> > I haven't heard about this issue from anyone else (except for zxq5). Most
> > people probably just leave the floating panels on by default, and therefore
> > never encounter a problem.
> > 
> > Still, its only been hours so I will report back if anything changes.
> 
> Can confirm the issue is happening for non-floating panels. I'll try setting
> them to floating mode and see if that solves my issue, thanks

It appears I spoke too soon. After a period of the screen being off, the problem appeared once when it came back on. That’s the only time so far since changing to floating panels so I will keep testing.

This happens to me every so often. I'm also on an AMD GPU. I am using a floating window as well. This is a regression from 6.0 as this did not happen to me before. A question for pete is do you have window previews enabled in the taskbar on hover? It might be related to pipewire.

(In reply to mr.yamamoto from comment #20)
> This happens to me every so often. I'm also on an AMD GPU. I am using a
> floating window as well. This is a regression from 6.0 as this did not
> happen to me before. A question for pete is do you have window previews
> enabled in the taskbar on hover? It might be related to pipewire.

I do have window previews enabled. Interesting idea, I'll try turning it off and see what happens. Testing with the opaque and floating settings is a mixed bag so far. With opaque enabled I had a few hard lock-ups that weren't fixed by maximizing/de-maximizing a window and actually had to restart. With floating and adaptive, it only happens rarely. Nothing I can see as a clear pattern so far.

*** Bug 484266 has been marked as a duplicate of this bug. ***

Update: no settings for the taskbar seem to prevent the issue, but leaving it floating seems to make it happen less often, and be more easily recoverable without restarting plasmashell.
One thing I notice that may help shed light on this (or just make it more confusing):

When my monitors wake up, the primary wakes up first and the secondary shows up a bit after. Part of that is definitely just different monitors acting differently but when the primary comes on, I can momentarily see a second taskbar appear on the primary before disappearing and reappearing on the secondary once it loads.
If I use the primary taskbar *right* before that happens, it works. But "right* after the secondary monitor's panel appears is when the primary panel stops working.

For the record ever since I switched to floating panel, I've yet to encounter the issue again

(In reply to yurapostates from comment #24)
> For the record ever since I switched to floating panel, I've yet to
> encounter the issue again

Interesting. What distro are you on and do you use any non-default options? I have middle-click set to close windows and I turn off "Mark applications that play audio". Everything else is default IIRC.

> Interesting. What distro are you on and do you use any non-default options?
> I have middle-click set to close windows and I turn off "Mark applications
> that play audio". Everything else is default IIRC.

Arch Linux. I have the default options afaik. I have middle click set to Opens a new window and Mark applications that play audio is turned on

Since 6.0.4, I haven't seen this issue at all. It may be resolved but I'll report back if it crops up again.

Oh wonderful, thanks for following up!