Summary: | Panel is unable to receive focus after opening Youtube video on Firefox | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Dan <dan76> |
Component: | general | Assignee: | David Edmundson <kde> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | bshah, hein, plasma-bugs-null |
Priority: | NOR | ||
Version First Reported In: | 5.8.4 | ||
Target Milestone: | 1.0 | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | qdbus org.kde.KWin /KWin supportInformation |
Maybe this is an issue with GTK+ apps, since I notice it happens more when I use Claws mail and Firefox. Whos knows? No, task bar just "freezed" just by hovering over the systray. It's something related to the task bar (or a bug somewhere else affecting the task bar). My guess is the plasmashell process takes 100% CPU and becomes unresponsive. (In reply to Eike Hein from comment #3) > My guess is the plasmashell process takes 100% CPU and becomes unresponsive. Hi Eike. I was just testing this: 1) I move the mouse over the systray over all icons very fast (showing all the tooltips) 2) after a few seconds, plasmashell consumes 30% of the CPU, and the tooltip gets stuck 3) then plasmashell CPU consumption goes back to normal (but the tooltip keeps stuck) The only messages I can see in the log are the following (when the tooltip is stuck): Initializing "kcm_input" : "kcminit_mouse" QXcbConnection: XCB error: 3 (BadWindow), sequence: 8389, resource id: 79691782, major code: 18 (ChangeProperty), minor code: 0 Initializing "kcm_input" : "kcminit_mouse" QXcbConnection: XCB error: 3 (BadWindow), sequence: 19207, resource id: 79691782, major code: 18 (ChangeProperty), minor code: 0 Initializing "kcm_input" : "kcminit_mouse" QXcbConnection: XCB error: 3 (BadWindow), sequence: 42301, resource id: 79691782, major code: 18 (ChangeProperty), minor code: 0 *** Does it make sense? (In reply to Eike Hein from comment #3) > My guess is the plasmashell process takes 100% CPU and becomes unresponsive. Eike, good news! Problem solved. After struggling for a week with this issue, the problem was with the xf86-video-intel driver. Since it defaults to DRI2, I simply enabled DRI3 (--enable-dri3) and added on my xorg.conf: Option "DRI" "3" This results on the following: [ 56.746] (**) intel(0): Option "DRI" "3" [ 56.902] (II) intel(0): [DRI2] Setup complete [ 56.902] (II) intel(0): [DRI2] DRI driver: i965 [ 56.902] (II) intel(0): [DRI2] VDPAU driver: va_gl [ 56.902] (II) intel(0): direct rendering: DRI2 DRI3 enabled [ 57.862] (II) GLX: Initialized DRI2 GL provider for screen 0 There's only 1 line which mentions DRI3 and I read somewhere the Intel driver doesn't use DRI3 at all. Well, I'm using the latest git version 2.99.917-746-g169c74fa and it indeed does solve the issue (or maybe this is an indirect consequence?). I don't know. So I'll mark this bug as WORKSFORME. Maybe it helps someone using the same setup. Ps: and I tested it with UXA and SNA. The only way to solve it is enabling DRI3. Thanks for following up! |
Created attachment 102825 [details] qdbus org.kde.KWin /KWin supportInformation Steps to reproduce: 1) open any video on Youtube (on Firefox 50.1 in my case) 2) hover the mouse over the task bar 3) repeat steps "1" and "2", 4 times or more 4) after the 4th attempt, the task bar can't receive the focus from mouse The "workaround" is to switch to the terminal (Ctrl+Alt+Fx) and go back to X (Alt+Fx), so the task bar receives the focus of the mouse again. I tried with many combinations of "Activating Windows Policy" and "Focus Stealing prevention", but it happens no matter what are your options. I tried to with OpenGL 3.1, 2.0 and Xrender with the same results. It seems this happens more with "Accurate" and less with "Crisp" scaling option, but maybe it's subjective. Ps: I attached the "qdbus org.kde.KWin /KWin supportInformation" output, just in case. Ps2: the log doesn't show any error message.