Version: unspecified (using KDE 4.5.2) OS: Linux When I play a Flash video (using adobe flashplugin) the fullscreen video is shown on the desktop - behind the browser window, panel etc. Example screenshot attached. This happens in Firefox, not in Chromium, and only on some websites (vimeo being one). I don't have Flash set up in Konqueror, so can't comment on that. xprop output from clicking the fullscreen video here: http://codepad.org/zzuuhwKi Problem is fixed by disabling focus stealing prevention for the browser. Reproducible: Always
Created attachment 52428 [details] Screenshot showing the problem
In case the pastebin expires, here is the xprop output linked above: _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 0, 0 _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0 _NET_WM_DESKTOP(CARDINAL) = 2 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_SKIP_TASKBAR WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x5a00001 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 94506504 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME(CARDINAL) = 8985499 _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 9079510 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x5a20e07 WM_CLIENT_LEADER(WINDOW): window id # 0x5a00001 _NET_WM_PID(CARDINAL) = 4541 WM_LOCALE_NAME(STRING) = "en_US.UTF-8" WM_CLIENT_MACHINE(STRING) = "panther" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified minimum size: 0 by 0 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "npviewer.bin", "Npviewer.bin" WM_ICON_NAME(STRING) = "npviewer.bin" _NET_WM_ICON_NAME(UTF8_STRING) = 0x6e, 0x70, 0x76, 0x69, 0x65, 0x77, 0x65, 0x72, 0x2e, 0x62, 0x69, 0x6e WM_NAME(STRING) = "npviewer.bin" _NET_WM_NAME(UTF8_STRING) = 0x6e, 0x70, 0x76, 0x69, 0x65, 0x77, 0x65, 0x72, 0x2e, 0x62, 0x69, 0x6e
acc. to the netwm spec, only active fullscreen windows are supposed to be on top of everything. what's your - focus policy - regular focus protection level then? are you unable to pass the focus to flash by clicking the window?
Focus policy: Click to focus Regular focus protection level: Low I can get the video on top by clicking on it or alt+tabbing to it.
I can confirm this bug - Kubuntu 10.04, KDE 4.4.2, Firefox 3.6.10, Flash Player 10,1,85,3 When I click on Fullscreen on some flash video, the video is shown in another window which is BEHIND Firefox window. Alt-Tab helps me to switch to it, but anyway it's annoying to click Alt-Tab every time when I switch to Fullsceen.
Ok, can confirm. FYI, It does /not/ happen in konqueror either. It's either FF or nspluginviewers or Adobes "fault*".... :-( The focus policy checks for several relations which do all not hold because the flash video runs in an external process (different PID - this is a design issue about flash that won't fix) with client leader different from FFs mainwindow (ie. "there's no explicity 'we're brothers' hint", FF could probably fix that), so it all falls down to a timestamp comparism. Testing with youtube video (flash) the usertime stamp ("last interaction") of the flash (fullscreen video) is newer than the one of the so far active (presumingly FF) client - good. Testing with vimeo, the timestamp of the *currently active client* (FF or maybe some interim layer) is newer than the one of the FS flash - bad (i don't know what hapens there in FF/flash, but this has to be interpreted as if the user is currently working on the current window, so the focus should not be autostolen by some random other client on the desktop) From KWin's side this is a "won't fix" - use a workaround rule, but FF could stress the relation between the browser and the flash viewer or explicitly request the focus for the flash player to ensure it gets it -> "UPSTREAM", meaning "someone elses fault" ;-P *focus protection is heuristic and not a fixed convention. The "standard" is "none", while kwin defaults to "low" for better experience, so actually it's not a real bug.
This bug affects me. Open a flash video in fullscreen, it opens in fullscreen behind the windows. There are a few exceptions to this as I know: 1) Youtube videos strangely dont seem to be having tht at present. Earlier they did have this problem. But they flicker when when volume is changed.
(In reply to comment #6) > Ok, can confirm. FYI, It does /not/ happen in konqueror either. > > It's either FF or nspluginviewers or Adobes "fault*".... :-( > > The focus policy checks for several relations which do all not hold because the > flash video runs in an external process (different PID - this is a design issue > about flash that won't fix) with client leader different from FFs mainwindow > (ie. "there's no explicity 'we're brothers' hint", FF could probably fix that), > so it all falls down to a timestamp comparism. > > Testing with youtube video (flash) the usertime stamp ("last interaction") of > the flash (fullscreen video) is newer than the one of the so far active > (presumingly FF) client - good. > Testing with vimeo, the timestamp of the *currently active client* (FF or maybe > some interim layer) is newer than the one of the FS flash - bad (i don't know > what hapens there in FF/flash, but this has to be interpreted as if the user is > currently working on the current window, so the focus should not be autostolen > by some random other client on the desktop) > > From KWin's side this is a "won't fix" - use a workaround rule, but FF could > stress the relation between the browser and the flash viewer or explicitly > request the focus for the flash player to ensure it gets it -> "UPSTREAM", > meaning "someone elses fault" ;-P > > *focus protection is heuristic and not a fixed convention. The "standard" is > "none", while kwin defaults to "low" for better experience, so actually it's > not a real bug. So wat's the workaround?
"kcmshell4 kwinrules", create a new rule, pick the flash window ("detect" and click it), enter the "workarounds" tab, check "focus policy", select "force" and "none", click apply. this should allow the flash window to steal the focus regardless of hints on its parents.
i have a question. how can i use this workaround? it is impossible to click on the fullscreen flash window, because as soon as i go to the window with the button to "detect ..", the fullscreen flash window disapears. Perhaps kwin should ship by default with that workaround installed?
it's actually not trivial (i managed it once, and to re-check i used a timered xwininfo*) unfortunately the situation apparently got worse: the window class is now "<unused>" (FF4, tested on vimeo) what's quite generic :-( just make a new rule, leave everything as it is, set classmatch to exact and put in <unknown> <unknown> then pick the focus rule override and apply. Notice that this might cover other clients as well, FF has to fix this upstream.
thx, worked. I still feel like there should be a workaround in kwin, considering firefox wont fix this and for most users it just looks like kde is broken (since it seems to work everywhere else).
a) There's no way to work around this, because there's no reliable way to detect that window. It apparently was classed "called" and is now "<unknown>", also FF has a loooong history of the stupid attitude to change the window class with /every/ minor release (FF4 is _now_ "Firefox" - we'll see whether it will stay like this or it's maybe even just a distro thing (not using the mozilla bin here) - so even very "sophisticated" (read: "complex heuristic") attempts to check for this client (which has at least now a faar to generic name to be just hardcoded as hidden bomb for future kwin devs) might fail with their next release. b) It's not the task of a WM to guess a sane client hierarchy into broken clients, esp. if we'd had to run after every other FF release to "fix" our workaround :-( c) Turning off focus stealing prevention would lead to the standard NETWM spec behaviour, so while a generally helpful feature the ffsp actually /is/ broken by definition :-( d) To get a usable workaround, we'd need to ensure that FF uses somewhat constant and unique client classes - but then they could as well just mark that window as transient to the Browser window and the entire issue was gone anyway. If they really need any advice on how to do that (using X11, i've no idea about gtk) they may safely ask (or google for XChangeProperty ;-)