Last modified: 2013-12-06 13:10:21 UTC
For some reason the menu causes the video to "flicker" on Safari Mac. It seems as if the video and the menu are racing for the highest z-index while you scroll the menu. You can see this on the elephants dream movie by going into the "Languages" menu of CC or by going to the download menu. The video has to be playing for the effect to be visible. The effect does not present on Firefox, Chrome for Mac crashes for me on mwEmbedplayer, possibly because <video> support on Chrome for Mac is unfinished. First I thought this was a bug in webkit, or in the ogg/video module, but I created a testcase with a scrollable element on top of a video element, and it worked just fine. Thus it has to be something more specific to the dom/css/JS events of the mwEmbed player. Possible causes, mouse events triggering a function that does something undesireable, broken z-index values.
I don't have a Mac Safari. Does mac safari let you live tweak the css values? Maybe there is something that can be done to diminish the effect? Does it flicker if the video is paused? Can we report the issue upstream? Video support for Chrome ( especially with ogg files ) does crash the browser interdependently of using the mwEmbed gadget. A few issue have been reported to the chrome folks. But would not hurt to do some more issue tagging on their bug tracker.
Terrible issue to investigate..... what makes it "show" after scrolling at the very least is the monitor in some way, because changing EmbedPlayer.MonitorRate, influences the time it takes to get the menu back on top. when the menu is not visible, it is BEHIND the video frame. it's not display:none'ed I have excluded xiphQT, because other types of videos trigger the same problem. I have excluded that it is a core issue of the video element, because a overflow scroll element on top of a video element does not cause the same problem. I have a testcase for this. could still be z-index or other render bug in webkit, but difficult to confirm with webkit folks, because they want a reduced testcase, which is an almost impossible task with this complicated player.
Seems related to the opacity of the <div class="overlay-win k-menu ui-widget-content"> is related to this problem. Quite likely a redraw bug in webkit.
Filed upstream: https://bugs.webkit.org/show_bug.cgi?id=48379 In the mean time, i guess we could consider removing opacity for safari...
Derk-Jan great work hunting this down! Good to see testcase for webkit upstream. Chrome does not display this behavior ( probably related to quicktime hardware acceleration draw issue ) Anyway as quick fix I removed the opacity property if your using safari in r75504 Could you test and see if that works?
Upstream is closed as WORKSFORME with this comment: --- Comment #7 From Simon Fraser (smfr) 2010-11-02 17:53:30 PST --- I can no longer reproduce on a nightly. This seems related to http://trac.webkit.org/changeset/54006, but r54005 doesn't show it so it may only occur on the branch that Safari 5 was built from.
Assuming this is fixed as per comment 6. Please reopen if that's not the case.
we also have a workaround for it in kplayer skin it seems. var userAgent = navigator.userAgent.toLowerCase(); if( userAgent.indexOf('safari') != -1 ){ $menuOverlay.css('opacity', '0.9'); }
