KDELibs 4.10.97 Qt 4.8.5 Reproducible: Always Steps to Reproduce: 1. Right click on a item. 2. use keyboard to navigate to "Close" 3. Press enter Actual Results: The menu shows again and then plasma crashes. Expected Results: Menu doesn't show again and plasma doesn't crash.
Created attachment 81498 [details] drkonqi backtrace Backtrace
I can't reproduce this - do you have any more steps to reproduce to offer?
Created attachment 81580 [details] Another backtrace with more symbols Was able to reproduce it on my system as well. Fedora 19, with kde-unstable KDE Development Platform 4.10.97
Git commit 4d5bac5f2206f01742334ee457714348e3ad7b9a by Eike Hein. Committed on 20/08/2013 at 17:53. Pushed by hein into branch 'master'. Ignore child event types we're not explicitly interested in. MouseEventListener listens to both child events and events passing through itself; child events are recorded so the handler for the latter can perform a comparison and avoid emitting signals for the same event again. However, this comparison could fail because the member used to record the last child event would also be updated for events we were not actually interested in. A real-world example of this is opening a popup menu in repsonse to a Press event. This causes an Ungrab event on the child, which would cause the comparison to fail and mousePressEvent to announce the same press yet again. M +4 -2 src/declarativeimports/qtextracomponents/mouseeventlistener.cpp http://commits.kde.org/plasma-framework/4d5bac5f2206f01742334ee457714348e3ad7b9a
Git commit 98f86dc15f98ab27b7d70b66bb7c44d3c6ea5581 by Eike Hein. Committed on 20/08/2013 at 17:59. Pushed by hein into branch 'KDE/4.11'. Ignore child event types we're not explicitly interested in. MouseEventListener listens to both child events and events passing through itself; child events are recorded so the handler for the latter can perform a comparison and avoid emitting signals for the same event again. However, this comparison could fail because the member used to record the last child event would also be updated for events we were not actually interested in. A real-world example of this is opening a popup menu in repsonse to a Press event. This causes an Ungrab event on the child, which would cause the comparison to fail and mousePressEvent to announce the same press yet again. This is a backport from plasma-frameworks 4d5bac5f. M +4 -2 plasma/declarativeimports/qtextracomponents/mouseeventlistener.cpp http://commits.kde.org/kde-runtime/98f86dc15f98ab27b7d70b66bb7c44d3c6ea5581
This commit causes a regression (tested on today's master): To switch between tasks, I now have to double-click them, while previously a single quick was sufficient.
Hm, I can't reproduce this at all here ... could you try to figure out if you can narrow this down to any sort of setting?
I am also affected by the double-click issue here. I really have to double-click (ie. the second click has to come within a short time), clicking twice with a larger time gap does not help. Very annoying.. Right click works as normal.
Unfortunately I absolutely cannot reproduce this here, and I tried tons of settings ... I had hoped Christoph might have more info, but maybe you do?
Let's move over to bug 324470 I'd say ...