Double click on titlebar is set to maximize. But after a while it suddenly stops working. Rebooting fixes the problem, but only to cause it again. I can still however, right click and "maximize". Reproducible: Always Steps to Reproduce: 1. Install Manjaro KDE 2. Use it for a while 3. Double click to maximze 4. Keep using it 5. It will stop working
please provide output of: qdbus org.kde.KWin /KWin supportInformation
Created attachment 92386 [details] qdbus org.kde.KWin /KWin supportInformation As requested.
No double click actions for the title bar work for me. I tried changing them after realizing that maximize/restore did not work in the hopes that something would work and then change it back. Nothing I change my double click action to works :( I've uploaded the information as requested.
*** Bug 347027 has been marked as a duplicate of this bug. ***
Not sure what exactly solved it for me but it works after doing a few things (that had nothing to do with solving this problem). I own an Nvidia card and use the proprietary driver. I've had some screen tearing and thought I try adding export __GL_YIELD="USLEEP" to /etc/profile.d/kwin.sh Once that was done, I then ran kwin_x11 --replace and it started working when I accidentally found out by double clicking a window to restore it. It worked. I then went into system settings and changed the title bar double click action to something else and it worked (nothing I changed to before worked). Not sure if it'll survive a reboot though. Good luck :)
Still an isue?
I'm using KDE 5.3(b) on Manjaro 8.13 rc. I can confirm that this is no longer an issue. Thanks :)
In which version is it solved? On debian I'm using 4:5.3.2-2 and it has the bug.
It's never been explicitly solved (nor has the issue been pinpointed) The problem simply "disappeared" for the reporter and he marked the bug as fixed (which is slightly inaccurate as resolution, but we don't really care) Please attach the output of "qdbus org.kde.KWin /KWin supportInformation" and check (afterwards) whether "kwin_x11 --replace &" temprarily resolves it.
Created attachment 93830 [details] Output of "qdbus org.kde.KWin /KWin supportInformation"
Can confirm both the bug and the temporary workaround with "kwin_x11 --replace &". Requested output iof attached. Running Debian testing.
Breeze decoration, no maximize effect. Did the problem ever re-occur after restarting kwin_x11 _once_ during a session, ie. is the problem limited to the instance started with the session?
I wish I could help more as I was hit with this "again". The thing is, I don't know how to reproduce it. I'm just not sure what causes it. It's pretty rare but there.
Created attachment 93851 [details] qdbus org.kde.KWin /KWin supportInformation I've attached results of "qdbus org.kde.KWin /KWin supportInformation" while suffering unresponsive titlebars and have something new to add. While titlebars are unresponsive (tested on several windows) if I right click I get a menu. If I double click while the menu is up, it'll do what it's supposed to. Then once it's maximized/restored, it's back to unresponsive again. I tried other actions like alt+middle click and windows are successfully sent back, just double clicking does nothing. Shift+alt+F12 to turn off effects, does not work. Shift+alt+F12 to toggle it back doesn't work. kwin_x11 --replace works. Not sure what else I can do to help here. Please ask. Thanks!
> tested on several windows Just to be 100% sure: this does not only affect GTK3 client-side-decoration windows, does it? Ie. it *does* also cover typical KDE applications like dolphin, konsole or kwrite and such. > if I right click I get a menu. If I double click while the menu is up, it'll do what it's supposed to. The popup actively grabs the input for the client, overriding any passive grab. Could be the passive grab delays event processing beyond the doubleclick timeout... => when this happens next time, run "kcmshell5 mouse" and in the 2nd tab, generously increase the doubleclick timeout (like a second or so) and see whether that has any impact on the matter.
I don't have gtk3 installed an I am experiencing the bug.
=> when this happens next time, run "kcmshell5 mouse" and in the 2nd tab, generously increase the doubleclick timeout (like a second or two) and see whether that has any impact on the matter.
I have the same problem on Kubuntu 15.04 with kubuntu-backport packages installed. Restarting kwin_x11 solves temporarely the issue.
I noticed that when it is not working the cursor changes to the "move window arrows" on the first click.
That means either the mouse got moved or the press wasn't accomplished by a release for quite some time - the drag activation delay. Can you please check the settings in "kcmshell5 mouse", notably - double click interval - drag start time - drag start distance?
I have the bug and I can reliably cause it to occur by changing the Dolphin settings to open with double click. I am using Kubuntu 15.04. Specifically, changing the setting at Control > Configure Dolphin... > Navigation > "Double-Click to open files and folders" causes the double-click on title bar to maximize to stop working. The move functionality is all I get. Once the bug appears, Changing it back to single-click doesn't correct the bug without a logout/in. The bug may also cause some serious flicker problems. There are other bug reports related to the Dolphin double-click setting which may be related.
Okay, so here is an addendum to my previous comment. It turns out that I only need to open the Dolphin settings to make the bug appear. Specifically, from Dolphin, click Control > Configure Dolphin... Then click OK. This makes the bug appear for me every time.
what does dolphin --version say?
I've just reliably made the bug happen as according to comment 21. Dolphin preferences > Navigation > single to double causes double clicking on the titlebar to break. When this happens, I can reliably work around it if I run kwin_x11 --replace. $ dolphin --version Qt: 4.8.6 KDE Development Platform: 4.14.9 Dolphin: 15.04.0
Not reproducible, sorry (though 4.8.7 and 4.14.10) @Kevin, what "other dolphin doubleclick bugs"? Can anybody please check comment #20 and increase those values, notably after the problem has manifested? (I could only imagine that the dolphin setting screws the doubleclick timeout and KWin picks that up, so you end up being unable to perform a doubleclick by system measures)
On Fedora 22 (updates and plasma-5-beta) Qt: 4.8.6 KDE Development Platform: 4.14.9 Dolphin: 15.04.0 The problem is reliably reproducible as according to comment 21. Checking what you asked, I have the following double clicking = 400 msec drag start = 500 msec drag distance = 4 pixels Doubling the values *after* the bug manifest itself, seems to fix the issue the way "kwin_x11 --replace" fixes it. Trying to reproduce the bug is no longer reliable for me. I'm thinking of actually keeping these settings after reading what each hint does (doesn't seem to bother me).
Ok, please keep the inscreased setting and see whether you can still re-cause the bug. If so, dolphin (or something it relies on) screws the systems doubleclick timeout (and we need to pass the bug on, so this is an important information to get it fixed - there may be no bug in KWin at all)
(In reply to Thomas Lübking from comment #23) > what does > dolphin --version > say? $ dolphin --version Qt: 4.8.6 KDE Development Platform: 4.14.6 Dolphin: 14.12.3 Note that the double-click may not be the trigger. Just in case my comment #22 got buried, I'd like to reiterate I only need to open the Dolphin settings and then click OK to trigger the bug (with or without changes). Concerning the "other Dolphin double click bugs", I believe I was grasping at straws to find something applicable and they now don't seem to apply (or even be bugs, necessarily), but for the record: https://bugs.kde.org/show_bug.cgi?id=348946 https://bugs.kde.org/show_bug.cgi?id=349397 https://bugs.kde.org/show_bug.cgi?id=347514
Can't see dolphin code which edits it, but could you run (while things work as expected) qdbus org.kde.kaccess /MainApplication GetAll org.qtproject.Qt.QApplication the trigger the issue by the dolphin settings dialog and run qdbus org.kde.kaccess /MainApplication GetAll org.qtproject.Qt.QApplication again. Then please post both outputs here.
Running: $ qdbus org.kde.kaccess /MainApplication GetAll org.qtproject.Qt.QApplication Cannot find '.GetAll' in object /MainApplication at org.kde.kaccess Am I making a mistake?
Not necessarily. The object is org.freedesktop.DBus.Properties so try: qdbus org.kde.kaccess /MainApplication org.freedesktop.DBus.Properties.GetAll org.qtproject.Qt.QApplication but qdbus should resolve that automagically. In doubt, check for the output of qdbus org.kde.kaccess /MainApplication | grep GetAll Also this is the interface of kaccess 5.4 - might be you're still on KDE/4 (you'll have to check the dbus interface then, I don't know how it was organized) qdbus org.kde.kaccess gives you a list of the objects qdbus org.kde.kaccess /MainApplication gives you all methods in "/MainApplication", given that object exists.
No progress, unfortunately: $ qdbus org.kde.kaccess /MainApplication org.freedesktop.DBus.Properties.GetAll org.qtproject.QtQApplication Cannot find 'org.freedesktop.DBus.Properties.GetAll' in object /MainApplication at org.kde.kaccess $ qdbus org.kde.kaccess /MainApplication | grep GetAll Service 'org.kde.kaccess' does not exist. $ qdbus org.kde.kaccess Service 'org.kde.kaccess' does not exist. $ qdbus org.kde.kaccess /MainApplication Service 'org.kde.kaccess' does not exist. $qdbus | grep kaccess $ Uhhh... Kubuntu 15.04 freshly installed last week.
kaccess got killed/crashed? $ ps ax | grep kaccess $ ls /usr/bin/kaccess $ /usr/bin/kaccess
From a fresh reboot: $ ps ax | grep kaccess 2065 pts/1 S+ 0:00 grep kaccess $ ls /usr/bin/kaccess /usr/bin/kaccess $ /usr/bin/kaccess QCoreApplication::arguments: Please instantiate the QApplication object first QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kf5.kiconthemes: "Theme tree: (Breeze)"
The $ 60.000 question is of course, whether staring kaccess made any difference wrt to this bug ;-)
I just installed Fedora 22 last night and have this problem in the fresh KDE install. I played with the window settings to no avail. Double click has been working fine in Dolphin and everywhere else, but I thought I'd take a look at the mouse options just in case. Drag start time starts at 500 ms and double click at 400 ms. Since the drag icon is what takes over the double click I thought why not... and changed double click to 500 ms and drag to 400 ms. Double click on windows now works correctly, and it doesn't seem to have broken drag anywhere that I can tell. Hope it helps.
The values are disjunct, ie. the doubleclick interval can legally be longer than the startDragTime (as long as you can keep your mosue steady ;-) The present theory is rather that "something" lowers at least one value drastically at some point. In that case a) the problem will show up again (the dolphin dialog seems to be a trigger) b) any change of the values to something "sane" will then"fix" it
*** Bug 357643 has been marked as a duplicate of this bug. ***
So I had this "bug" and screwed around with the mouse settings a bit to fix it. I'm guessing that dragging starts after you hold for the "drag start time" OR move the pointer the "drag start distance" while holding. So, I wondered, how come it thinks it's dragging when I'm not holding for the drag start time or moving it the drag start distance? Then I saw "pointer threshold" was 4px - the same value as "drag start distance". I'm not sure exactly how KDE handles these values, but it seems to be subtracting "pointer threshold" from "drag start distance" As in, if both are 4px you only need to move the pointer 0px to trigger drag starting. I just decreased pointer threshold to 2px by resetting to defaults, and have had no problem since. What I'm not sure of is how pointer threshold got set to 4px in the first place - I know I didn't do it. My guess is that some installs, for some reason, are setting this value to the same or greater value as "drag start distance", even though the default is lower. Why would a new install not be set to defaults?
The acceleration threshold is not related to DnD or this bug. Afawcs, "something™" lowers either the doubleclick interval or the DnD timeout drastically - dolphin, resp. its config dialog, resp. whatever lib call that invokes is suspected, but we don't know for sure.
My point is just that in my case the problem wasn't that something lowered the doubleclick interval or DnD timeout below the defaults.. it was that something raised the "pointer threshold" above the default distance.
The pointer threshold describes when the mouse starts accelerated movement, ie. one real pixel is translated to to on screen etc. It's completely unrelated and certainly not the cause of your problems. And 4px is actually low - i think the default is 8px or some such. https://docs.kde.org/trunk5/en/kde-workspace/kcontrol/mouse/index.html
Just encountered this on Kubuntu 16.04 (on VirtualBox 5 on Windows 10). Double clicking on taskbars began having no effect. The problem began recently after many weeks of normal behavior. I did recently open my Mouse KDE Control Module to try and figure out what was going on with an unrelated virtualbox mouse bug (cursor position a few pixels off) but pressed the "defaults" button on the Control Module after messing around. The double click interval was at 400 msec. I tried changing it to 800ms and the problem persisted. BUT! Then I changed it back down to 400 and as soon as I clicked apply, the problem was fixed!
KDE Plasma Version: 5.5.5 QT Version: 5.5.1 Just installed fresh Kubuntu 16.04 and had this issue. Looks like there could be a problem with "Drag start time" option not being recognized initially or after changing its value to 0. Behaviour: clicking title bar instantly shows drag icon, double click is not recognized. To fix: go to Setting > Input > Mouse and click "Apply" button to save settings (you will need to change any option back and forth so the Apply button becomes active) To reproduce: 1. Set "Drag start time" to 0ms, Apply 2. Set "Drag start time" to something else, like 100ms, Apply 3. Try doubleclicking the title.
Woohoo, I figured out why this happens. :D -Single click initiates the "double click". ..Ages pass; -User tries to doubleclick, -BUT the first of these clicks is part of the previously initiated double click.. ------------ You're welcome.
This bug is still active in 5.7.5. Double click on title window won't shade (in my case) in about 60% of tries. Double click time is set to 400 msec.
And I can confirm #45: triple click always works.
If I remember correctly we fixed this. In case you are still able to reproduce on 5.11 please reopen.
Hi. In my end on 5.13.2 this issue persists. Triple-clicking does not work. However, if I: 1. right-click on the title bar while keep the right mouse button pressed. (the context menu will pop up) 2. Move the cursor away from the menu, but still on the title bar. 3. Double-click on the title bar. This will work.
Bug confirmed on fresh Archlinux installation using KDE framework 5.52.0, Qt 5.11.2 and default KDE settings. Triple click doesn't work. Double click doesn't work. Double click while RMB is pressed works (but it opens the contextual menu).
(In reply to FiNeX from comment #50) > Bug confirmed on fresh Archlinux installation using KDE framework 5.52.0, Qt > 5.11.2 and default KDE settings. > > Triple click doesn't work. Double click doesn't work. Double click while RMB > is pressed works (but it opens the contextual menu). Cannot confirm. Double click title bar works, it will consistently perform the action I've set it up to (Lower), using the following versions in openSUSE Tumbleweed: KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2
If I restore my old ~ home directory the bug is no more reproducible. Maybe something went wrong on default settings? I've recorded a short video: https://youtu.be/ft0BU2Hzpz0
Update: after playing with Plasma/Kwin settings, like enabling and disabling things randomly, I've saved the settings and on next reboot the bug disappeared on my account. If I create a new user account it does have the bug.
Created attachment 117760 [details] last updates #MeToo Suddenly I've got this problem too. Running Solus, so my Plasma environment is pretty bleeding edge. Tripple click doesn't help. Got no proprietary graphis driver. Anything you want to know, I should test?
Works again! KDE-Plasma 5.14.5 KDE-Framewords-Version 5.54.0 Qt-Version 5.11.2 (Solus 3.9999)
Look, I think I have got a reliable way to reproduce the bug. People please take a look and have a try at your end, thank you. Go to System Settings -> Applications -> Default Applications -> Web Browser, change how urls are opened any way you like. Try double-clicking. It should stop working. Take a look at this screencast: https://vimeo.com/user93204887/review/327057535/ba77f5a39c
link doens't work
(In reply to David Edmundson from comment #57) > link doens't work Sorry, never used vimeo before. Please try this: https://vimeo.com/327057535?activityReferer=1
(In reply to Savor d'Isavano from comment #56) > Look, I think I have got a reliable way to reproduce the bug. People please > take a look and have a try at your end, thank you. > > Go to System Settings -> Applications -> Default Applications -> Web > Browser, change how urls are opened any way you like. > > Try double-clicking. It should stop working. > > Take a look at this screencast: > > https://vimeo.com/user93204887/review/327057535/ba77f5a39c I can reproduce. Operating System: Arch Linux KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2
I've been facing this bug since a long time ago, so I decided to report it here too. I'm currently using Manjaro KDE 18, but I experience the same bug using KDE Neon and Arch Linux with Plasma desktop. I managed to reproduce it by enabling "Double click" in Workspace settings instead of single clicking. I can reproduce it with this way on both distribution.
yes, I also can reproduce after changing single/double click setting in system settings > desktop behavior > general behavior. Running "kwin_x11 --replace" with krunner (Alt+space) solves the problem. Operating System: Arch Linux KDE Plasma Version: 5.16.90 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1
I can confirm this is still happening. The workaround from Patric Silva on running "kwin_x11 --replace" seems to work for now. Time will tell if it continues or reverts back to not working. Linux/KDE Plasma: KDE neon 5.17 with kernel 5.3.0-28-generic KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.13.2
(In reply to fullpc from comment #60) > I've been facing this bug since a long time ago, so I decided to report it > here too. I'm currently using Manjaro KDE 18, but I experience the same bug > using KDE Neon and Arch Linux with Plasma desktop. I managed to reproduce it > by enabling "Double click" in Workspace settings instead of single clicking. > I can reproduce it with this way on both distribution. I can reproduce it too, works 100% of times on laptop (haven't cheked on arch kde pc) Linux/KDE Plasma: Manjaro Linux 19.0.0 with kernel 5.4.18-1-MANJARO KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1 Using kwin-lowlatency: https://github.com/tildearrow/kwin-lowlatency
Reproducible on Plasma 5.19 beta. Maximizing with double click on window decoration stops working after I change any setting in system settings > workspace behavior > general behavior. No longer reproducible on changing the default internet browser as mentioned in comment 56 though. Operating System: Arch Linux KDE Plasma Version: 5.18.90 KDE Frameworks Version: 5.70.0 Qt Version: 5.15.0 rc2
Reproducible on 5.18.5 on Fedora as well
I have a hunch that this might be related to Touchpad/Mouse settings (may be length of movement for touchpad/mouse from which it starts detecting a "drag" action instead of "double-click" action?).
I no longer can reproduce with the steps from comment 64 on Arch Linux (Plasma 5.22) or neon unstable. Can anyone? Tested both Wayland and X11 sessions.
*** This bug has been marked as a duplicate of bug 421450 ***