User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release) Build ID: 20130618035212 Steps to reproduce: 1) Go to http://andy2343.tumblr.com/newembed 2) Press the fullscreen button in the player Actual results: The Tumblr follow/dashboard controls are displayed on top of the player in full screen. Expected results: Just the player should be displayed.

Thanks for reporting this! I can't reproduce this bug on Firefox but I'm on Mac OS 10.8.4 Brad, could you try to verify if the problem exists in Firefox Safe Mode? https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems?redirectlocale=en-US&redirectslug=Basic+Troubleshooting#w_3-restart-firefox-in-safe-mode

My apologies, looks like that is using our Flash player because it doesn't have the mozallowfullscreen attribute on it. I'll get a different test page set up ASAP.

Here is an isolated test case: http://brad.is/reportingbugs/positionfixed/

I can reproduce it with the url provided. I'll put this in the Core::Layout component, not really sure it's the right component.

This is more or less as designed. Remove (or just lower) the z-index from the fixed-pos element and it should be OK.

Hi Robert, That's not really a possibility for us as a third-party iframe. There is no way for our Vimeo embeds to be able to tell that there will be elements from the outer page overlaid on top of our player in full screen, potentially preventing users from accessing our controls. When the website owner allows our iframe to go into full screen, I believe that it's expected that when it happens, our iframe will occupy the entire screen. Perhaps for a first-party iframe it is reasonable for the pos:fixed element to be on top, but I personally wouldn't expect it even for that.

Tumblr's position;fixed elements only appear on top because they have z-index:2147483647. Decrease that by one and everything would be fine. The way that this should work was only defined by CSS relatively recently and we need to change our implementation to match, but that isn't very high priority at the moment :-(.

Tested and confirmed again with the link provided in comment 3

This will be fixed by bug 1126230.

This should have been fixed by bug 1126230. Reopen if it is still reproducible on Nightly.

Confirmed fixed in Nightly. Thanks!