The panel auto-hide works fine on system start-up. However after sometime it stops working. Not sure what triggers it to stop. Looks like starting up certain applications / adding widgets can trigger it. Reproducible: Always Steps to Reproduce: 1. Shift panel to left edge of screen. 2. Customize the panel by adding a widget or two and application shortcut or two. 3. open up a few application windows. 4. Un-hide the panel by moving mouse to left edge of screen. 5. Attempt to re-hide panel by moving mouse away from left edge of screen. Actual Results: Panel won't re-hide. Stays visible until system restart. (not sure what can trigger it to hide properly again) Expected Results: Panel should re-hide. AMD64 llano quadcore, 8 GB RAM Linux openSUSE 13.1 Root partition 70 GB. Swap 7.5 GB Default theme (mostly).
I've been seeing this in recent months, though eventually the panel re-hides without restarting the system. My panel is at the bottom of the screen. I have "automatic mounting of removable media" enabled (System Settings / Removable Devices or secondary click on Device Notifier tray icon / Removable Devices), and the problem seems to occur more often after I unmount a USB stick. It can occur at other times as well, so I don't know.
It has got worse after a largish online update performed on 08/Feb/2014. Now the panel remains visible soon after clicking on the openSUSE application launcher. The location of the panel (left or top) does not seem to play any role. It is really an inconvenient blot on an otherwise smooth experience, particularly as I need as much screen space as possible on the desktop but have to make do for the moment with 1440x900.
I have Kalarm docked in the panel, and I've found that clicking on it hides the panel. So now I'm wondering if it's Kalarm at fault. I intend to keep a record of when the panel "sticks" and see if there's any correlation with alarms I've set up. Of course, since I had the idea about 4 days ago, the panel hasn't stuck...
I've done these things in an effort to resolve the problem: * Disabled automounting through System Settings / Removable Devices * Removed kalarm from the panel * Configured Akregator to turn off the tray icon. Still the panel pops up for no apparent reason (also bug 314968) and stays popped up. Clicking the right-hand "cashew" causes it to hide. This happens every few days, maybe a couple of times in one day.
Personally, I don't think it is possible to figure out what causes this bug without actually debugging from source. I work around the panel obscuring the bottom of the scrollbar by reducing the x-size of the panel slightly. But often the lower part of the window I want to work on gets obscured also and that can be annoying. I was wondering if there can be a temporary bug-fix for this such as allowing manual hiding and un-hiding. So in case it refuses to auto-hide, clicking on a "hide" button on the panel toolbox would hide it. Best Regards.
I had a go last year sometime using kdebugdialog to get debugging info for plasma-desktop, but didn't find anything from that. It would be good if the panel could emit debug messages saying why it's popping up, but I don't think it does.
What surprises me is that nobody else has reported this bug either on kde bugs or on other distribution specific sites - For example the openSUSE.org forum. There are reports of other problems with the panel auto-hide - such as pane refusing to _un_hide, or panel hiding in the middle of the screen etc, but not a single report of panel refusing to hide again. There have been reports of similar problems on openSUSE 11.x but not on 13 or 13.1. After six months of openSUSE 13, one would think that _someone_ would have encountered this problem. I have no unusual widgets, just the following: 1.Notes 2.Weather 3.Dropbox (but the problem occured even before installing dropbox) 4.Clipboard. 5.Volume 6.Device Notifier 7.Bluetooth. 8.Notifications/Network Management. 9.Time/Date 10.Redshift. 11.System Load viewer. The only other thing I can thing of is Matlab which sees daily use. Moreover the problem can occur on system startup merely by clicking the application launcher. Perhaps I should put this up on the openSUSE.org forum. Regards, SKM
Have posted this on openSUSE.org: [url]https://forums.opensuse.org/showthread.php/498393-Panel-Auto-Hide-Stops-Working-After-Some-Time-Panel-does-not-Rehide?p=2646170#post2646170[/url] Hopefully someone other than the two of us has seen this problem. Regards, SKM.
The only widgets I have in common with you are: Clipboard Volume System Tray (including Notifications, Application update notifier and Device Notifier) Time/Date I don't use bluetooth (except for very occasionally plugging in a USB dongle), and I have a static network configuration. I use Kubuntu. I gradually restored the widgets I mentioned in comment 4, and I was beginning to think the problem had gone until I upgraded from Kubuntu 13.10 to 14.04. Now the problem has re-appeared, but it's no worse than before my experiment in comment 4; if anything, it's slightly better.
I forgot to mention I regularly mount and unmount a CIFS share, and I sometimes automount an NFS share. There might be some association with the panel problem, but that's far from certain.
OK, I really spent some time fiddling with this today. I found that the 'NOTES' widget was causing the problem in my case. This is how I was led to it:- 1. I clicked each widget in turn to get it to show its popup and then clicked away from it to dismiss it. 2. I found that _some_ of the widgets did not seem to "let go" in the sense that after dismissing their popup, the panel refused to rehide. This included for example the weather, date and time and also the 'application launcher menu' (which presumably is after all a widget). 3. So my first instinct was to remove these widgets one by one - but unfortunately even after removing all the 'clingy' widgets the panel still refused to rehide after clicking on the 'application launcher'. 4. Other widgets were well behaved - in particular the 'Notes' widget was being particularly nice. Whenever I clicked and dismissed the 'Notes' widget the panel would stop misbehaving and rehide. So I had a specially warm feeling towards the 'Notes' widget. 4. At this point I thought that the problem lay with the application launcher itself - so was about to give up. 5. But monkey-like instincts caused me to continue clicking on widgets and I realized one thing. When the panel was in its stubborn 'not going to rehide' state, then the moment I clicked and dismissed the 'Notes' widget, the panel would start working properly again. There was _no_ other widget that exhibited this pleasing behaviour that the 'Notes' widget was demonstrating. 6. On the off-chance I decided to remove the notes widget (after apologizing profusely to it) and ... Lo and behold the panel started working perfectly! It is of course quite possible that there are other widgets that cause the same problem and a future widget could upset the current happy state of affairs. For example here are some possible useful links: https://bugs.kde.org/show_bug.cgi?id=267735 A discussion here for an older version 11.4 of openSUSE: http://codeverge.com/opensuse.org.help.applications/11.4-kde-autohide-taskbar-not/1907059 One of the developers on his efforts to work around this issue in openSUSE 11.4: http://aseigo.blogspot.in/2011/03/panel-hiding.html Best Regards, SKM
(In reply to modysk from comment #11) > OK, I really spent some time fiddling with this today. I found that the > 'NOTES' widget was causing the problem in my case. This is how I was led to > it:- > > 1. I clicked each widget in turn to get it to show its popup and then > clicked away from it to dismiss it. > > 2. I found that _some_ of the widgets did not seem to "let go" in the sense > that after dismissing their popup, the panel refused to rehide. This > included for example the weather, date and time and also the 'application > launcher menu' (which presumably is after all a widget). > > 3. So my first instinct was to remove these widgets one by one - but > unfortunately even after removing all the 'clingy' widgets the panel still > refused to rehide after clicking on the 'application launcher'. > > 4. Other widgets were well behaved - in particular the 'Notes' widget was > being particularly nice. Whenever I clicked and dismissed the 'Notes' widget > the panel would stop misbehaving and rehide. So I had a specially warm > feeling towards the 'Notes' widget. > > 4. At this point I thought that the problem lay with the application > launcher itself - so was about to give up. > > 5. But monkey-like instincts caused me to continue clicking on widgets and I > realized one thing. When the panel was in its stubborn 'not going to rehide' > state, then the moment I clicked and dismissed the 'Notes' widget, the panel > would start working properly again. There was _no_ other widget that > exhibited this pleasing behaviour that the 'Notes' widget was demonstrating. > > 6. On the off-chance I decided to remove the notes widget (after apologizing > profusely to it) and ... Lo and behold the panel started working perfectly! > > It is of course quite possible that there are other widgets that cause the > same problem and a future widget could upset the current happy state of > affairs. For example here are some possible useful links: > > https://bugs.kde.org/show_bug.cgi?id=267735 > > A discussion here for an older version 11.4 of openSUSE: > http://codeverge.com/opensuse.org.help.applications/11.4-kde-autohide- > taskbar-not/1907059 > > One of the developers on his efforts to work around this issue in openSUSE > 11.4: > http://aseigo.blogspot.in/2011/03/panel-hiding.html > > Best Regards, > SKM Thank you! You seemed to have nailed it! Notes is off my panel now. Apologetically, of course!
(In reply to Poorav from comment #12) > (In reply to modysk from comment #11) > > OK, I really spent some time fiddling with this today. I found that the > > 'NOTES' widget was causing the problem in my case. This is how I was led to > > it:- > > > > 1. I clicked each widget in turn to get it to show its popup and then > > clicked away from it to dismiss it. > > > > 2. I found that _some_ of the widgets did not seem to "let go" in the sense > > that after dismissing their popup, the panel refused to rehide. This > > included for example the weather, date and time and also the 'application > > launcher menu' (which presumably is after all a widget). > > > > 3. So my first instinct was to remove these widgets one by one - but > > unfortunately even after removing all the 'clingy' widgets the panel still > > refused to rehide after clicking on the 'application launcher'. > > > > 4. Other widgets were well behaved - in particular the 'Notes' widget was > > being particularly nice. Whenever I clicked and dismissed the 'Notes' widget > > the panel would stop misbehaving and rehide. So I had a specially warm > > feeling towards the 'Notes' widget. > > > > 4. At this point I thought that the problem lay with the application > > launcher itself - so was about to give up. > > > > 5. But monkey-like instincts caused me to continue clicking on widgets and I > > realized one thing. When the panel was in its stubborn 'not going to rehide' > > state, then the moment I clicked and dismissed the 'Notes' widget, the panel > > would start working properly again. There was _no_ other widget that > > exhibited this pleasing behaviour that the 'Notes' widget was demonstrating. > > > > 6. On the off-chance I decided to remove the notes widget (after apologizing > > profusely to it) and ... Lo and behold the panel started working perfectly! > > > > It is of course quite possible that there are other widgets that cause the > > same problem and a future widget could upset the current happy state of > > affairs. For example here are some possible useful links: > > > > https://bugs.kde.org/show_bug.cgi?id=267735 > > > > A discussion here for an older version 11.4 of openSUSE: > > http://codeverge.com/opensuse.org.help.applications/11.4-kde-autohide- > > taskbar-not/1907059 > > > > One of the developers on his efforts to work around this issue in openSUSE > > 11.4: > > http://aseigo.blogspot.in/2011/03/panel-hiding.html > > > > Best Regards, > > SKM > > Thank you! You seemed to have nailed it! Notes is off my panel now. > Apologetically, of course! Many thanks for your efforts! The Notes causes this problem. However the Notes widget can remain in panel. I discovered that in a "pathological" state when I click the widget and the windows opens I click right hand side mouse button to open the Notes menu and click "Speak Text", then error message appears "Starting Jovie Text-to-Speech Service Failed" and panel returns to the "healthy" state again. This procedure is probably necessary after each use of Notes.
Correction: After a while panel again returns to its "pathological" state. The procedure proposed in my last comment helps only temporarily and has to be repeated frequently. Regards, Tomek
I am seeing the same issue, but only recently. Likely some "fix" propagated into the openSUSE repos recently. It seems to correlate with windows being closed, but is not an "always" thing. Moving my mouse onto and off of the panel will allow it to re-hide.
This topic is also discussed in https://bugs.kde.org/show_bug.cgi?id=340549 and https://bugs.kde.org/show_bug.cgi?id=361566 Adding a 2nd virtual desktop as suggested in https://bugs.kde.org/show_bug.cgi?id=362105 as a workaround works for me.
Still happens with openSUSE 42.2 running plasma 5.8.6. In contrast to similar issue bug 351823 this one is annoyingly persistant. I guess for the first time today I experienced that a plasma panel with active auto-hide being permanently visible already after starting KDE. Toggling the auto-hide state two times does not help (as usual). Interestingly I found killing plasmashell and restarting properly restored the configured auto-hide behaviour in this situation!
It has been *FOUR* years now. This still happens on a regular basis and this bug is still marked, "UNCONFIRMED". My "System Settings" says Version 5.8.8, so I assume that is the KDE version, too, but the Frameworks is 5.36.0. So I do not know what the KDE version is. I've rebooted a few times, but to no avail.
This bug had been corrected on Wheezy and re-appeared (with many others) after my recent upgrade from Jessie to Strech. My system settings says: Using: KDE Frameworks 5.28.0 Qt 5.7.1 (built against 5.7.1) I can't believe Stretch has been released "Stable", bugged as it is. I recently had a complete X11 crash after a click to clos a window. In 15years using Debian I never saw such a week version !
Was able to reproduce the bug - opened few new apps, minimized/unminized some - and panel stops hiding - bottom panel, 4 virtual desktops, 2 activities Plasma: 5.12.2 Apps: 17.12.2 Frameworks: 5.43.0 Qt: 5.10.1 Kernel: 4.14.22-1-MANJARO OS: Netrunner Rolling
Same problem here with Fedora 26 and plasmashell 5.10.5. No Notes used.
Hi, in my case panel auto-hide breaks after virtual desktop change or when I open new app. On that panel I have the following widgets: - icon only task manager, - tasks monitor - digital clock. The one that breaks auto-hide of panel is task manager/switcher with enabled option “show tasks only from current desktop”. When you disable this option (task switcher shows all running apps from all desktops) panel auto-hide works fine. You can also fix it by moving the mouse on the panel and after that it hides correctly. Maybe this is related with Bug 394119. Os: Mint 18.3 Plasma: 5.8.9 KFrameworks: 5.36.0 QT version: 5.6.1
I'm still seeing this bug, randomly, but daily, in 5.14.2. It's often after switching from one app to another, the taskbar (whether set on auto-hide or allowing windows can go over taskbar) won't hide again. It can be on some apps and not others at the same time. It persists despite plasmashell being killed and restarted, which lead me to wonder if it was a widget problem keeping the taskbar activated. So, as a test, I deleted the widget "Task Manager" from the taskbar, just having the "start menu" and system/app icons/clock on the right on my taskbar. So far, after several hours of use, the problem of the taskbar not hiding is gone. So I wonder if it's actually a Task Manager Widget bug, and not a taskbar bug.
Don't know if that helps but in my case I realized that autohide seemed to not work cause an unfocused window was asking for some answer or produced some new output. Focusing to that window makes autohide working again.
Sadly, no, that's not my situation, as I'm constantly using all my open apps. Thus far, I'm almost at all day without the Task Manager widget in the taskbar and have yet to have a single autohide issue, which would be a first for a full day for me. If that seems to be it, I'll put a bug report in for the Task Manager.
@tmp6 Actually, I wonder if your solution is the same problem as I'm describing with the Task Manager. Something "waking it up" that the Task Manager isn't resolving. That would explain why even rebooting plasmashell doesn't help, because the widget still thinks something is unresolved.
I haven't experienced the bug in KDE 5. Maybe my Task Manager settings are relevant: Show only tasks from the current desktop Show only tasks that are minimised
" I'm constantly using all my open apps" Of course you use it but can you watch at every opened task in the bar ? Depending on your template, the asking task highlighting might be nearly invisible. I use "Breeze light" desktop theme and I have to put my nose on the task bar to see whitch one is highlighted.
I want to confirm this issue and add a few words. This happens regularly, since I started using Plasma about a month ago. The trigger is unknown to me; often it can be bettered by randomly switching desktop, minimising/maximising windows, or whatever. But not always; like now, the panel is stuck and even switching it to "Always visible" does not work (full-screen windows do not shrink to not be under the panel). As with the trigger, I've not found a single dependable way to correct it. As an aside: I've found this behaviour over the years not just in KDE, but in /all/ desktop environments I've used, for example XFCE, and also in Microsoft Windows. Rather than focussing on heuristically trying to find what widget or application might be triggering it, it should be recognised as a fault in the panel (or whatever underlying structures it uses). This issue is many years old, unsolved, and nobody has ever found a singular trigger for this issue. I expect a solution will only come from properly analysing the behaviour of the panel, possibly with user-accessible debug output. Operating System: Debian GNU/Linux KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.12.5 Kernel Version: 5.6.0-2-amd64 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-2520M CPU @ 2.50GHz Memory: 7.7 GiB of RAM --- OS: Debian GNU/Linux bullseye/sid x86_64 Model: Dell System XPS L502X Kernel: 5.6.0-2-amd64 Uptime: 1 day, 8 hours, 18 mins Packages: 5419 (dpkg) Shell: bash 5.0.16 Resolution: 1920x1080, 1920x1080 DE: Plasma WM: KWin Theme: Breeze [Plasma], Breeze [GTK2/3] Icons: breeze [Plasma], breeze [GTK2/3] Terminal: xfce4-terminal Terminal Font: Noto Sans Mono Condensed 12 CPU: Intel i5-2520M (4) @ 3.200GHz GPU: NVIDIA GeForce GT 525M GPU: Intel 2nd Generation Core Processor Family Memory: 6368MiB / 7923MiB ---
I'm seeing the same issue (with both autohide and "windows can cover") on my fresh Devuan "Beowulf" install, and I can confirm Vlijmen's remark that this is not a new issue. I tend to get it from time to time on my Plasma4 desktop too (which I'm keeping for a reason on my main workhorse and would install it everywhere if packages still existed: it works!). There, it is always related to a window that "has something to tell me" and shows up highlighted in the task manager; clicking on it (or else on all task man. entries) always fixes the issue in the end. I have a similar experience with the MSWin taskbar: if it won't go back to its designated place it's usually if not always because of some notification that I have to acknowledge (after figuring out which/what it is). So a potential solution might be to provide an additional setting where you can disable the panel coming to the front because of a notification.
Hah, I think my assessment wasn't wrong. I use xfwm4 instead of KWin (sorry guys :)) and for once I ran it in a terminal. When the update notifier came on, I saw this: (xfwm4:21597): xfwm4-WARNING **: 13:58:49.644: Unmanaged net_wm_state (window 0x260027c, atom "_NET_WM_STATE_STAYS_ON_TOP") (xfwm4:21597): xfwm4-WARNING **: 13:59:34.096: Unmanaged net_wm_state (window 0x2000068, atom "_NET_WM_STATE_STAYS_ON_TOP") (xfwm4:21597): xfwm4-WARNING **: 14:02:15.715: Unmanaged net_wm_state (window 0x2000068, atom "_NET_WM_STATE_STAYS_ON_TOP") (xfwm4:21597): xfwm4-WARNING **: 14:02:50.340: Unmanaged net_wm_state (window 0x200005c, atom "_NET_WM_STATE_STAYS_ON_TOP") I think that proves that the panel does indeed sometimes override our user preference for it NOT to be on top all the time.
And FWIW, that wm_state did NOT get unset after I applied the update or even disabled the update notifier thingy.
Created attachment 131102 [details] pin the notifications The only way so far I could force the panel to stay unhidden is by pinning the notifications. Then switching desktops, the notifications stay behind on the first desktop. But the panel refuses to hide on the second desktop as well. This will cause the tray-area to have a highlight as a visual clue, that one of the tray-icons is the reason the panel is kept open (you can check how the visual clue looks in your design by opening / closing the notifications). Otherwise I can only second the suggestion, to provide some debug command for asking all the panels to dump the reason why they think, they have to be visible. And if the smoking gun is in the hand of the taskmanager, it should itself blame the window-title and process that makes him in return request attention. Otherwise I hope for bug 394119 to alleviate this by allowing to dismiss the panel on mouse-over.
Re: mouse-over: I used to be able to get the panel to hide (or go under) again by waving the mouse over it. I wonder, wouldn't it be a solution to add a setting to tell panels never to bring themselves to the front? A priori that should be independent of whether or not notifications appear frontmost (though I'll admit that I'd just as well NOT have most of those pop up in front of whatever it is I'm looking at and steal focus).
After years of experiencing this issue I have the impression that this issue may correlate with the usage of multiple panels. In my setup I typically instantiate four of these for different purpose at different screen edges in a multi-monitor setup, most of these with auto-hide enabled. E.g. one of these panels exclusively containing a single virtual desktops widget on the right edge and with dimensions as big as possible (unfortunately this use case is not anticipated by the developers, but that's a different story) and in consequence it is auto-hide, of course. The thing is that this panel will begin to ignore its auto-hide property after some days or weeks of usage. Even worse, when removing this and trying to add a new one with the same properties this tends to ignore its auto-hide setting right from the beginning. IMO, as crazy as it sounds, plasma has a bug in properly maintaining the settings of multiple panels with similar settings. HTH Stefan
I managed to resolve this issue: System Settings -> Display an d Monitor -> Compositor -> Keep windows thumbnail -> 'Only for shown windows' (was 'Always') Cheers, A.
Anton, your issue is probably something else; likely Bug 456988.
(In reply to antonmx from comment #36) > System Settings -> Display an d Monitor -> Compositor -> Keep windows > thumbnail -> 'Only for shown windows' (was 'Always') I am very glad that that worked for you. Sadly, that was my setting, so it is not the cause of my failure-to-hide. :( I'm still wasting the real estate.
I'm affected as well by this bug, strangely, I have 2 computers using the same distribution, each uptodate at the exact same version, and only one is affected. The one being affected is having a fixed top panel, and an auto hide bottom panel. I'm using Plasma version 5.26.4, Frameworks version 5.101.0, Qt version 5.15.7 and Kernel version 6.0.12. I'm using X11 and nvidia proprietary drivers. On the top panel (fixed), I have: * the K application menu (Application dashboard) * A spacer * Systray * 2 app icons (table symbols, systemsettings) * Digital clock * User switcher * a folder view * trash bin icon * transparency panel addon On the bottom panel (auto hide) I have: * Icon only task manager * transparency panel addon
(In reply to Filipe Azevedo from comment #39) > On the bottom panel (auto hide) I have: > * Icon only task manager > * transparency panel addon Check the Task Manager settings and verify that "Unhide when a window wants attention" is *not* checked. This preventing auto-hide working for me. Hope this helps.
(In reply to hugo_NL from comment #40) > (In reply to Filipe Azevedo from comment #39) > > On the bottom panel (auto hide) I have: > > * Icon only task manager > > * transparency panel addon > > Check the Task Manager settings and verify that "Unhide when a window wants > attention" is *not* checked. > > This preventing auto-hide working for me. Hope this helps. This does not seems to be my issue, but to be sure I tested - does not help. My issue is not that the panel remain visible as per say, but that a ghost of it remain on the desktop, so clicking this ghost does nothing. From what I can see the reject / close animation is not operating and ghost appear. When I move the mouse cursor to the bottom to enable the panel visibility, the open animation operate and at this time the ghost disappear but to come again once the mouse cursor leave the panel.
On Thursday January 05 2023 09:23:08 Filipe Azevedo wrote: >My issue is not that the panel remain visible as per say, but that a ghost of >it remain on the desktop, so clicking this ghost does nothing. >From what I can see the reject / close animation is not operating and ghost >appear. Are you using KWin and does the ghost disappear when you restart it (`kwin_x11 --replace` for X11 or kwin_wayland for Wayland; personally I add `--no-kactivities`). I had plenty of glitches of (parts of) windows or the desktop not being redrawn properly, which turned out to be related to compositing. That all went away when I selected the XRender rendering backend. I'm not certain what kind of compositing that does, but the few effects I like to see (including windows turning semitransparent when moving) are supported. As a bonus I seem to be getting less tearing when watching videos. R
I have same issue Arch Linux with latest updates(06/03/2023). Each time a facing this problem I just restarting plasmashell: [code] kquitapp5 plasmashell && plasmashell [/code]
There is a shortcut key to change focus between panels (just like Alt+Tab for windows), it is Meta+Alt+P. Pressing the shortcut (as many times as panels you need) will make the panel reaper. It is a good workaround to recover a hidden panels without having to minimize all windows.
(In reply to RJVB from comment #42) > Are you using KWin and does the ghost disappear when you restart it > (`kwin_x11 --replace` for X11 or kwin_wayland for Wayland; personally I add > `--no-kactivities`). > I had plenty of glitches of (parts of) windows or the desktop not being > redrawn properly, which turned out to be related to compositing. That all > went away when I selected the XRender rendering backend. I'm not certain > what kind of compositing that does, but the few effects I like to see > (including windows turning semitransparent when moving) are supported. As a > bonus I seem to be getting less tearing when watching videos. Sorry for the long delay, I tested just now ad yes it disappear but still get ghosted as soon as I trigger the panel visibility. I did not tested xrender because I wan to use the opengl backend, and this would just hide the problem - not fixing it.
This issue from 2014 has unfortunately become un-actionable. The original issue is most likely fixed now, judging by a lack of other related recent bug reports, so it's likely that everyone else reporting "me too!" here is actually experiencing a different issue with a different root cause. I would recommend that everyone except for modysk@gmail.com open a *new* bug report describing their issue in detail. And modysk@gmail.com, if you could re-open this issue only if it's still happening to you in Plasma 5.27.7, that would be great. Thanks everyone!