Bug 373738 - Panel is unable to receive focus after opening Youtube video on Firefox
Summary: Panel is unable to receive focus after opening Youtube video on Firefox
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 5.8.4
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-17 00:36 UTC by Dan
Modified: 2016-12-19 11:12 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
qdbus org.kde.KWin /KWin supportInformation (6.10 KB, text/plain)
2016-12-17 00:36 UTC, Dan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan 2016-12-17 00:36:13 UTC
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.
Comment 1 Dan 2016-12-17 00:39:23 UTC
Maybe this is an issue with GTK+ apps, since I notice it happens more when I use Claws mail and Firefox. Whos knows?
Comment 2 Dan 2016-12-17 01:05:11 UTC
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).
Comment 3 Eike Hein 2016-12-17 22:27:56 UTC
My guess is the plasmashell process takes 100% CPU and becomes unresponsive.
Comment 4 Dan 2016-12-17 23:04:08 UTC
(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)
Comment 5 Dan 2016-12-18 04:49:49 UTC
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?
Comment 6 Dan 2016-12-19 00:36:44 UTC
(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.
Comment 7 Eike Hein 2016-12-19 11:12:29 UTC
Thanks for following up!