Created attachment 769340 [details] screenshot The embedded youtube video at http://metro.co.uk/2013/06/28/manager-in-peru-gets-sent-off-for-tripping-rival-player-from-his-technical-area-3860971/ cannot be loaded properly for me. I'm using the 2013-06-28 UX build that MattN recommended for testing UX stuff. I think there were some recent changes with click to play, now when I get flash video I get a small doorhanger asking "Allow now" or "Allow and remember", not sure if this is related. Directly assessing http://www.youtube.com/embed/CqppNMjKU6Y?version=3&rel=1&fs=1&showsearch=0&showinfo=1&iv_load_policy=1&wmode=transparent seems to work though. Matt, do you mind testing this out?
MattN pointed out that nightly might also be affected, and true enough, I just tested that 2013-07-06 nightly build is also affected. Does someone mind retesting this as well?
This issue reproduces back to Firefox 18 and it's Mac OSX specific (not reproducible on Windows and Linux). Last good nightly: 2012-10-14 First bad nightly: 2012-10-15 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=57304bbf9c0e&tochange=942ed5747b63
Thanks Ioana. I would guess this was caused by bug 626245. It seems like wmode=transparent has something to do with it not being visible. When I remove that parameter from the iframe URL, the video is visible but I still can't click on it. I'm marking affected versions based on the regression range alone.
Setting needinfo from :roc based on comment 3. Thanks Matt!
Markus might be able to look into this. First thing to check is what nsDisplayPlugin::ComputeVisibility does and why that is making the plugin invisible sometimes.
As of recent nightlies, this seems to WFM. Ioana, do you mind double-checking please?
I've tried to reproduce this, but the video displayed without any issue on Mac OS 10.6 and 10.9, with latest Nightly 33 and Beta 31. However note that I also got no issues with Nightlies from 2013-07-06 and 2012-10-15 (the video displays and works without problems).
Nonetheless, WFM then. I'm sure we'll file a new bug when this occurs again.