SUMMARY From time to time within applications using XWayland, the window focus will break and it will be impossible to interact with the window anymore. This often occurs when you right click within the application or when you minimize the application and then restore it later. (When this problem occurs it also seems to cause current, or later right clicks to not register, requiring to you either logout, or try to minimize/restore the window a couple times until it decides to start working again) This problem occurs even if you don't have a second monitor, however it seems to effect secondary monitors more so. STEPS TO REPRODUCE 1. Run a xwayland application (Firefox, Chromium, Spotify, Discord, Thunderbird) 2. Minimize it to the task bar, Restore it 3. If it doesn't loose focus, do it a few more times. You can also try right clicking, especially within Firefox (v63) (The behavior is seemingly random) OBSERVED RESULT Windows will no longer detect input you give them, but are still seemingly focused in regards to the window Titlebar. EXPECTED RESULT Right clicks register and display their menus, Text is detected, Mouse clicks are recorded at all times. SOFTWARE/OS VERSIONS Operating System: KDE neon Developer Edition KDE Plasma Version: 5.14.80 (5.12, 5.13, 5.14) Qt Version: 5.11.2 KDE Frameworks Version: 5.53.0 Kernel Version: 4.19.1-041901-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz Memory: 15.6 GiB of RAM ADDITIONAL INFORMATION From the testing I've done, all plasma versions from at least (didn't test further than that) 5.12 and up are affected. This is the Reddit post i made a few days ago, which someone has replied to saying that they encounter this when using applications in their second monitor: https://www.reddit.com/r/kde/comments/9vd65y/wayland_application_focus_and_multimonitor_bugs/
I have the same problem on my system. Operating System: Arch inux KDE Plasma Version: 5.14.3 Qt Version: 5.12 beta4 KDE Frameworks Version: 5.52
What exactly do you mean with "loose focus"?
I have encountered the issue with firefox since it is the most common xwayland app I use. I believe here "Loosing focus" means no mouse input work : you click on the window but the window does not react accordingly. In my experience I could use the keyboard though. For instance in firefox I could use Ctrl + Tab to switch tabs.
I can reproduce this issue, at a time that I thought this would be hard are issue. I don't exactly know pattern to reproduce this but yes this is annoying.
*hardware
I cannot reproduce and have not encountered the problem.
Same. Can't reproduce but I'll try to describe as much as I can. Last time this happened I was using Sublime Text 3 and my VM was in the background. I tried to close a file and a modal from ST3 showed up (Save changes to New file before closing?). It quickly vanished and my clicks stopped working. I tried to alt+tab to find the second window and I also checked if they were behind other windows, it just vanished. When I was using alt+tab I noticed that on top of my virtual machine (top left corner) I could see the vanished modal with a black background but it wasn't functional, more like a glitch. Maybe a good candidate to trigger this bug is to open a Windows 10 VirtualBox machine with 3D acceleration enabled (but that might skew the results since it should be off afaik), switch to full screen mode and try to use the host OS. SOFTWARE/OS VERSIONS Operating System: Kubuntu 18.10 PPA: kubuntu-ppa/backports KDE Plasma Version: 5.14.3 Qt Version: 5.11.1 KDE Frameworks Version: 5.51.0 Kernel Version: 4.18.0-11-generic OS Type: 64-bit Plasma Wayland session, Intel iGPU only Virtualbox 5.2.18_Ubuntu r123745, mouse integration enabled Behavior observed when any of my vms were open: - Windows 10 guest, 3D Off, 2D On (256MB) - Linux guests, 3D and 2D off
(In reply to Martin Flöser from comment #6) > I cannot reproduce and have not encountered the problem. That's weird. Yeah, the problem is that the Xwayland application looses focus after a while... I'll see if i can record it, it's extremely random, but it really breaks the workflow when it keeps re-occurring.
Was able to reproduce not responsive to mouse clicks Telegram window once in multi-monitor setup - one above other with panel on upper external 24" 1440p monitor and Telegram window on lower 14" 1080p laptop monitor Telegram 1.4.3 install through snap Operating System: KDE neon Developer Edition KDE Plasma Version: 5.14.80 KDE Frameworks Version: 5.53.0 Qt Version: 5.11.2 Kernel Version: 4.15.0-39-generic
I was able to reproduce it with a single monitor again today. Sorry for the bad quality, my phone's camera does not have stabilization and i compressed the video a bit to save space. https://drive.google.com/open?id=1KQuJ8t8V50EkjJnUOvBR_D4yzMf7z2Yh
Today it happened twice on my system with VLC player. VLC was playing a video in background, I switched from another app (kate and ksysguard) to VLC, VLC appeared on the screen with frozen video while audio was playing normally. Nothing happened when I clicked on VLC until I minimized and restored its window, then the video unfroze and mouse clicks worked again. Operating System: Arch Linux KDE Plasma Version: 5.14.3 Qt Version: 5.12.0 beta4 KDE Frameworks Version: 5.52.0 Kernel Version: 4.19.2-arch1-1-ARCH
To anybody encountering the problem: please go to Compositor settings and change "Keep window thumbnails" to "Always". That's the setting I have and which could explain why I don't see the problem. If you can confirm that this fixes the problem we can remove the setting and enforce it on Wayland. The setting doesn't really make sense on Wayland, that's why I have set it to Always.
I just found a way to reproduce: open Firefox and unmaximize its window move Firefox window near to plasma panel right click your wallpaper on the space between Firefox and plasma panel while context menu is open, click Firefox entry in plasma panel (context menu closes) click Firefox entry in plasma panel again (Firefox is minimized) click Firefox entry again to restore it Now mouse clicks on Firefox window have no effect I can't reproduce after set "Keep window thumbnails" to "Always" in compositor settings. Wayland session crashed here when I configured "Keep window thumbnails" to "Always". Is this a know problem?
(In reply to Martin Flöser from comment #12) > To anybody encountering the problem: please go to Compositor settings and > change "Keep window thumbnails" to "Always". That's the setting I have and > which could explain why I don't see the problem. I did and had to reboot, some UI elements went black. > If you can confirm that this fixes the problem we can remove the setting and > enforce it on Wayland. The setting doesn't really make sense on Wayland, > that's why I have set it to Always. It's been a few hours and I haven't encountered the bug so far. It most definitely helped (probably fixed it but I need to use the system for a few days). P.S.: VirtualBox's fullscreen mode is broken for me (accel on or off) and it looks exactly like this bug where mouse clicks stop working in the host or guest system. I'm not sure it's related or just something not implemented yet. I thought I should mention it.
I'm not sure if changing the setting caused this, or if it's a separate bug, but for me the focus issue alot worse (it now seems to persist after going back to the original settings). Sometimes when i click a element in a application, the window isn't even focused now, and it clicks through the window (Both xorg and wayland). This is really, really weird.
Update: I haven't experience the bug again so far, it's very likely fixed with the suggested workaround. -- For people still having trouble with VirtualBox: If after the workaround you still have the bug in certain machines you can fix it by installing guest additions. The problem is it won't work until you edit the machine and make the window bigger, it triggers something I'm not aware (probably the same as resizing in the GUI but I can't click that so). Close virtualbox before editing the .vbox file. <ExtraData> <ExtraDataItem name="GUI/LastGuestSizeHint" value="1920,900"/> <ExtraDataItem name="GUI/LastNormalWindowPosition" value="680,-17,640,480,max"/> </ExtraData> This worked for me even for a pure server guest with no X and no 3d.
I found a working reproducing method. I have a two screens setup a 2560x1440 and 1280x1024. My main screen is the biggest one on the left of the other one. Whenever I move a xwayland app to the right screen from the left one, the window becomes unresponsive to clicks and keyboard. I get a weird behavior: when I click on the window or use the scroll wheel a xwayland window on the other screen gets clicked and scrolled and the current xwayland window flickers. Except the position of those clicks on the other window are not right. Meanwhile at each click, The taskbar shows me that the window focus is changed from the not-working window to the one on the other screen. Depending on this focus, the keyboard input follows from one window to the other. Sometimes this behavior appears spontaneously for a window that did not change of screen. It works with vlc, spotify, firefox. Kubuntu 18.10 Linux 4.18.0-11-generic KDE Frameworks 5.52.0 Qt 5.11.1 lspci | grep VGA 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] (rev cf)glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 560 Series (POLARIS11, DRM 3.26.0, 4.18.0-11-generic, LLVM 7.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.2 I can add more details if needed. I hope this helps !
Same graphics processor i have (Gigabyte RX 560 4GB OC). Perhaps it's related?
bug persists. Operating System: Arch Linux KDE Plasma Version: 5.14.90 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.0
Persists on the latest 5.15.80 plasma git. Workaround does not work at all.
The focus issues on multi-screen setups will likely be fixed with: https://phabricator.kde.org/D19255 Focus issue on single monitor setups might be a race fixed by: https://phabricator.kde.org/D19262
Git commit 5afbaa5e43f923db491628d8d848e3070c92dc94 by David Edmundson. Committed on 25/02/2019 at 14:13. Pushed by davidedmundson into branch 'master'. Only commit XdgOutput::done if changed Summary: XdgOutput no-ops if one calls setLogicalSize(someSize) and someSize matches the last sent size However, as we have an explicit done signal, we currently end up sending this regardless. This patches tracks if we've made any changes to commit in the done event. Reviewers: #kwin, romangg Reviewed By: #kwin, romangg Subscribers: romangg, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D19255 M +7 -0 src/server/xdgoutput_interface.cpp https://commits.kde.org/kwayland/5afbaa5e43f923db491628d8d848e3070c92dc94
Thank you very much! Seems to be fixed now in KDE Neon Git Unstable.
It seems the bug is still present to a lesser degree for some apps in wayland. The act of minimizing and maximizing windows to fix the focus no long works very well for it either. Also now affects Kwin titlebars of the affected applications.
Created attachment 120366 [details] Logfile which includes period when the focus issue occured. Not sure if this has any related errors to the focus bug, however there was some other issues during the time that i was testing, and i did encounter the focus bug with Minecraft, Steam, And Firefox.
This problem is still happening. :( Operating System: Arch Linux KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0
Yup. All versions of plasma. I'm really hoping it will get resolved for 5.17, but because nobody knows what's causing it, i imagine it wont be fixed for a while unfortunately. I've since switched back to Xorg with Kwin-lowlatency to get the smoothest experience.
I recently had a notification popup cause discord to loose focus on a Xorg session, just like this bug. Further, two minutes ago steam just lost focus as well, and would not let me input anything until i minimized it and maximized it again. It might not be the same bug, considering i can just minimize to reliably fix it, but i am starting to wonder if it's not just Wayland with this issue. No errors in kwin, or any odd system logs.
(In reply to Brian from comment #28) > I recently had a notification popup cause discord to loose focus on a Xorg > session probably it is bug 394772
This bug persists on Plasma 5.17 beta. Workaround: disable tooltips in task manager settings. Operating System: Arch Linux KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1
(In reply to Patrick Silva from comment #30) > This bug persists on Plasma 5.17 beta. > Workaround: disable tooltips in task manager settings. > > Operating System: Arch Linux > KDE Plasma Version: 5.16.90 > KDE Frameworks Version: 5.62.0 > Qt Version: 5.13.1 That doesn't do anything for me. Nor does disabling window thumbnails as previously mentioned in earlier comments.
(In reply to Brian from comment #31) > That doesn't do anything for me. Nor does disabling window thumbnails as > previously mentioned in earlier comments. You are right, the workaround does not solve the problem definitely. It have just happened on my system with VLC player. However, now the problem occurs less often here at least.
(In reply to Patrick Silva from comment #32) > (In reply to Brian from comment #31) > However, now the problem occurs less often here at least. I think the problem occurring more or less is just a factor of luck, as the problem seems very random. Minimizing and Restoring a window could be fine eleven times, and then the next it's not. Then you'll sit there minimizing and restoring the window until it regains keyboard/input & content rendering, and it will come back after a random number of times. It's almost like the content is lost behind the desktop, with a frozen frame still shown in the window. However in the past i even had Kwin's tilebars display similar behavior, usually when i had used a theme that wasn't breeze. I'm wondering if it's not partly a issue in Xwayland. It would be nice to know if this issue can be reproduced on Gnome too, to try and isolate the issue from plasma.
That said, I've also noticed on Firefox in Plasma Wayland on my Ryzen 3500U laptop with Vega 8 graphics, that Firefox seems to stop rendering content, but the buttons such as the refresh button continue to show the little hover highlight. When i minimize the window and bring it back up, the page shows to be refreshing, unlike before. This is extremely weird. I'm quite worried that because it's so erratic, and could be ten different issues at once, that it wont ever be resolved. Doesn't help either that we can't definitely determine if certain settings influence the issue, and that there seems to be no error logs for plasma.
I have been using the Gnome Wayland session on my laptop running Arch Linux for several years and have never seen this issue here.
Can bug priority be changed? This is a pretty big issue, and i think it should get some attention before 5.18. Otherwise, Wayland will continue to be essentially unusable on AMD graphics cards (Vega 8 & 11 APUs, and Radeon RX 400 & 500s from my testing). I've tested it on a bunch of hardware and have reproduced it each time. Intel hardware doesn't seem affected at all.
I use intel hd graphics and this issue affects my system.
(In reply to Patrick Silva from comment #37) > I use intel hd graphics and this issue affects my system. Ah sorry. I didn't recall the people reporting it on Intel too. As i showed from my comment, it's not easy to detect sometimes because of how random it can be. So it could definitely be some kind of race condition in kwin, or a bug in XWayland.
I'm not able to reproduce it. Is there a way to reproduce it consistently? I tried method in comment 13, but didn't fail for me.
(In reply to Roman Gilg from comment #39) > I'm not able to reproduce it. Is there a way to reproduce it consistently? I > tried method in comment 13, but didn't fail for me. No, that's the issue. It's extremely random. The way i an eventually reproduce it on various machines is to use a bunch of Xwayland applications and minimize them, restore them, and right click inside them. Eventually you should notice some odd behavior, like firefox not showing the right click menu, a website frozen in firefox after restoring a minimized window, discord showing someone is typing frozen and not letting you input anything after restoring it, and spotify not letting you click on anything in it's UI because it's window is frozen after restoring it.
(In reply to Roman Gilg from comment #39) > I'm not able to reproduce it. Is there a way to reproduce it consistently? I > tried method in comment 13, but didn't fail for me. Been doing testing and i think what might be happening is the window below is randomly getting input such as mouse clicks (the desktop?), leading to kwin mistakenly thinking you clicked something else, and therefor stopping you from inputing text. Meanwhile kwin renders the last thing the window was showing, leading to the still content seen. This surface glitching seems to happen most often with Firefox in Xwayland. In my experience when it happens, dialogs will open but not show, but if you use kwin's present window hotcorner you can see that it did infact open and that it's artifacted and invisble. Interestingly i just had the surface glitching happen randomly when downloading a file. The dialog opened, but it was artifacted and almost fully invisible, yet i could still click on it's titlebar. As a matter of fact, i know extremely similar behavior to this can be reproduced easily if you open Firefox with it's Wayland backend enabled. You will not only see tons of artfacting and misplaced UI elements should you move it or interact with it, but you will also find that some of your clicks are not registered and that windows below it are clipped up through it, giving you a mangled mess.
Probably not mouse clicks actually. But either way, my guess is that something is wrong with the window surface handling. Windows might glitching between each other leading to the surface clipping symptoms, and also the input/content rendering issues of this bug report (Maybe the input is actually being recieved, just not either A: to the right application (because of focus being sent to the wrong application), or B: not rendered because of clipping/surface issues).
For me it happens randomly (but often) when I have wine and virt-manager windows open. The wine window continues playing sound but doesn't respond to input. Since the start of this bug report I've changed GPU brand, drivers, distribution, KDE version but it was always present. But after changing "Keep window thumbnails" to "Always" as suggested here it became way less problematic. XWayland Firefox doesn't glitch for me anymore while using it, although I'll assume a startup bug I have is unrelated (say 1 every 50 times I open Firefox it opens as a small unclickable/unfocusable window).
(In reply to wg9rffujwz8y276u from comment #43) > For me it happens randomly (but often) when I have wine and virt-manager > windows open. The wine window continues playing sound but doesn't respond to > input. Since the start of this bug report I've changed GPU brand, drivers, > distribution, KDE version but it was always present. But after changing > "Keep window thumbnails" to "Always" as suggested here it became way less > problematic. XWayland Firefox doesn't glitch for me anymore while using it, > although I'll assume a startup bug I have is unrelated (say 1 every 50 times > I open Firefox it opens as a small unclickable/unfocusable window). For me changing the thumbnails setting did nothing, however i definitely get this in wine games frequently too. For me firefox dialogs being unfocused are the main issue, and opening links using the right-click menu causing the whole firefox window to loose focus, but it sounds like your problem could be related too.
just happened with Discord on Arch Linux running plasma 5.18 beta. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.0
I haven't had any major issues with window focus in 5.19 as of recently. I believe this bug is finally resolved.
I also have not seen this problem on my Arch running recent Plasma versions. But it's still happening on neon unstable. Maybe it's a problem with older Xwayland version running on neon unstable.
Appears this bug has not gone away, or if it did, it's back. I've tested Void Linux, Arch Linux, Kubuntu, Neon, Arch with 5.20 beta from kde-unstable, and KDE Neon git unstable with 5.20... All of which have the same problem.
This bug just happened with VLC Player on my system. Operating System: Arch Linux KDE Plasma Version: 5.19.90 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1
*** Bug 427604 has been marked as a duplicate of this bug. ***
(In reply to Brian from comment #41) > (In reply to Roman Gilg from comment #39) > > I'm not able to reproduce it. Is there a way to reproduce it consistently? I > > tried method in comment 13, but didn't fail for me. > > Been doing testing and i think what might be happening is the window below > is randomly getting input such as mouse clicks (the desktop?), leading to > kwin mistakenly thinking you clicked something else, and therefor stopping > you from inputing text. Meanwhile kwin renders the last thing the window was > showing, leading to the still content seen. > > This surface glitching seems to happen most often with Firefox in Xwayland. > In my experience when it happens, dialogs will open but not show, but if you > use kwin's present window hotcorner you can see that it did infact open and > that it's artifacted and invisble. > > Interestingly i just had the surface glitching happen randomly when > downloading a file. The dialog opened, but it was artifacted and almost > fully invisible, yet i could still click on it's titlebar. > > As a matter of fact, i know extremely similar behavior to this can be > reproduced easily if you open Firefox with it's Wayland backend enabled. You > will not only see tons of artfacting and misplaced UI elements should you > move it or interact with it, but you will also find that some of your clicks > are not registered and that windows below it are clipped up through it, > giving you a mangled mess. This sounds similar to the issue I've seen for a long time. The easiest way to reproduce this behavior for me is to: 1. Open one XWayland application (e.g. Thunderbird) and minimize it 2. Open another XWayland application (e.g. VLC) 3. In the second XWayland application, hammer on a menu bar option (e.g. in VLC you could continuously click on the Help menu to activate and deactivate the menu). You should be able to see invisible activations of the menu. This only happens for me when I have an XWayland window minimized. It also seems to stop happening with "Keep Window Thumbnails" set to "Always". Note that if needing to turn off the "Always" setting to reproduce this, the minimized XWayland window needs to be minimized *after* changing the setting off of "Always".
(In reply to Kyle Tirak from comment #51) > (In reply to Brian from comment #41) > > (In reply to Roman Gilg from comment #39) > > > I'm not able to reproduce it. Is there a way to reproduce it consistently? I > > > tried method in comment 13, but didn't fail for me. > > > > Been doing testing and i think what might be happening is the window below > > is randomly getting input such as mouse clicks (the desktop?), leading to > > kwin mistakenly thinking you clicked something else, and therefor stopping > > you from inputing text. Meanwhile kwin renders the last thing the window was > > showing, leading to the still content seen. > > > > This surface glitching seems to happen most often with Firefox in Xwayland. > > In my experience when it happens, dialogs will open but not show, but if you > > use kwin's present window hotcorner you can see that it did infact open and > > that it's artifacted and invisble. > > > > Interestingly i just had the surface glitching happen randomly when > > downloading a file. The dialog opened, but it was artifacted and almost > > fully invisible, yet i could still click on it's titlebar. > > > > As a matter of fact, i know extremely similar behavior to this can be > > reproduced easily if you open Firefox with it's Wayland backend enabled. You > > will not only see tons of artfacting and misplaced UI elements should you > > move it or interact with it, but you will also find that some of your clicks > > are not registered and that windows below it are clipped up through it, > > giving you a mangled mess. > > This sounds similar to the issue I've seen for a long time. The easiest way > to reproduce this behavior for me is to: > > 1. Open one XWayland application (e.g. Thunderbird) and minimize it > 2. Open another XWayland application (e.g. VLC) > 3. In the second XWayland application, hammer on a menu bar option (e.g. in > VLC you could continuously click on the Help menu to activate and deactivate > the menu). You should be able to see invisible activations of the menu. > > This only happens for me when I have an XWayland window minimized. It also > seems to stop happening with "Keep Window Thumbnails" set to "Always". > > Note that if needing to turn off the "Always" setting to reproduce this, the > minimized XWayland window needs to be minimized *after* changing the setting > off of "Always". I have suspicion it's not just XWayland applications affected. But yes, the main problem is XWayland ones.
I have never seen this bug. Do you know a way to reproduce it?
(In reply to Vlad Zahorodnii from comment #53) > I have never seen this bug. Do you know a way to reproduce it? The main way to reproduce it is to restore and minimize a XWayland window such as spotify, discord, or Firefox XWayland a couple times... You'll notice it will stop accepting input, and if you try to resize the window while the focus is out of whack, the border resizes but the content does not, as it's no longer updated. The bug is very random, and i recall it happening as far back as 5.12 Sadly because of how random it is you can go a while before even encountering it, and some developers here said they couldn't replicate the bug i assume due to that. That's actually why i marked this as solved for a while, thinking it was resolved, when in reality i was just lucky to not encounter it for a while.
I was testing the latest Plasma from Git, and the bug is still there. I can now say for certain however that the bug only affects XWayland applications, as I've done extensive testing to see if it happens with normal Wayland apps.
I'm using Wayland session on Arch Linux right now. This bug happened with Opera internet browser and Discord a few minutes ago. :( Operating System: Arch Linux KDE Plasma Version: 5.20.3 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2
Is there a focus check done in kwin to see if a window is open and being used? The clipboard not working with Xwayland apps, the window cycling breaking when an XWayland application is in main focus, and XWayland windows loosing input after a while... Is there perhaps an issue with Kwin's focus checks? Perhaps it's bugging out and stops realizing that an XWayland application is in focus, and therefor the clipboard, window input, etc no longer operate correctly?
https://www.youtube.com/watch?v=LjHwT1f2u7M
The isssues i've had with the clipboard must be related to the focus breaking. https://invent.kde.org/plasma/kwin/-/blob/0549c14588e0ccdbd4d78bb710e1c7569b409247/xwl/clipboard.cpp (Line 141 checks window focus before allowing clipboard actions... but if the focus is broken, then it obviously can't access the clipboard.)
So far i have not had this issue occur with a git build of Plasma which has the compositing rework patches. I tentatively want to say this was fixed, however the only way to know for sure will be to continue using it for some time and testing it on other distros. Anyone else able to confirm if the issue is gone with the latest git?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!