I am using an (old fashioned) frameset (not an IFrame). One frame is supposed to host the application and allows various elements to be fullscreened

works fine in firefox but not on webkit

Hello,

I'll hack around it, but I wanted to let you know that I can't just test BigScreen.enabled in IE8 because there is an unchecked use of "addEventListener" in the code that is throwing an error. Therefore BigScreen doesn't exist, and a fatal error occurs when looking for a property on the undefined object.

Thanks!

Noah

BigScreen.onexit = function() {
//Do Something
};

This method is working on latest version of chrome & in IE, but not on firefox.

Using latest Bigscreen version v2.0.5

Just wanted to let you know that the demos on http://brad.is/coding/BigScreen/ no longer work. It seems that you embed the JS files directly from the github repo.

Because GitHub was sick of acting like a faux-cdn, the files are sent with a mime-type of plain/text. Modern browsers will no longer attempt to execute JS that has the wrong mime-type.

It looks like some of the files may have changed as the request fails.

There's a bug on exiting full screen from within a full-screened iframe nested in a previously full-screened document. This bug shows up in Webkit browsers like Chrome or Opera (I think Safari too). For example, if I have a Youtube video in the document of an iframe, and I make a parent document containing that iframe full screen via Fullscreen API first and then click "Full screen" button in a video then I can't exit the full screen mode properly. Please, see the simplified attached code.

fullscreen-api.zip

Is there a way to bypass this bug?

Hey Brad, I wanted to give you a heads up on a possible bug.

When entering and exiting fullscreen mode multiple times in Safari, sometimes a "gray screen of death" overtakes the window. Strangely, the content begin fullscreened still seems to execute (proved, in my case, by still-playing audio from a HTML5 video) but there is no UI anymore and you can't interact with the gray screen.

I believe this bug is separate from the layout issue you describe here: http://openradar.appspot.com/radar?id=1878403

Here's a video: https://www.youtube.com/watch?v=PUT0OAY7S3Q

Steps to reproduce:

1. Go to multiple fullscreen demo page http://brad.is/reportingbugs/multiplefullscreen/
2. Click the demo image multiple times

I'll update this issue if I make any progress. Thank you.

Nothing happens when I click the fullscreen button in the demo.

This is preventing all of the demos on your site from working.

Hello,

I am using Brunch witch support bower components, but it demand new version of config file. 'component.json' is deprecated. It should be now 'bower.json'. And compiler of brunch has error.

Could you change it to new supported version?

Any plans to support Chrome 32+?

Thanks!

My Vimeo embeds work with BigScreen on my desktop, but not on iOS.

It looks like it fails during BigScreen.videoEnabled($('iframe)[0]). Is there a way to bypass this?

FYI: Vimeo support states that their API does not integrate with native JS fullscreen.

Hello,

This plugin was working inside iframe but when 2 level of iframe nesting applying on it reruns false on BigScreen.enabled.

Any solution ?

Having some trouble setting changing an iframe's background color to when in fullscreen mode. I understand that the default background color of the browsers visual environment is black when in fullscreen mode, but it seems it IS possible to override this with css.

http://stackoverflow.com/questions/16163089/background-element-goes-black-when-entering-fullscreen-with-html5

I have been trying to kung-fu this for the last day. Can someone please point me in the right direction?

Let me edit this into oblivion. Everything is working nicely... or acceptably if not perfectly. Thanks!

(the expanding element needs something like: width: 100%; height: 100%; in order to show nicely once you hit full screen in Chrome -- not required for other browsers, where other elements can be sized)

I haven't nailed down why this is happening, but these events are not being fired. This issue affects Firefox only.

I tested this in Firefox 45.0 -- but I suspect this is happening in other versions also.

Here is a minimum test case with jQuery that will reproduce the issue:

function onEnterFullscreen() {
    alert("I don't fire in Firefox!");
}

function onExitFullscreen() {
    alert("I also don't fire in Firefox!");
}

$('#photo-demo img').on('click', function() {
    if (BigScreen.element !== this) {
        BigScreen.request(this, onEnterFullscreen, onExitFullscreen);
    }
    else {
        BigScreen.exit();
    }
}); 

I've tried to write a unit test to reproduce this issue, however the Unit Tests do not actually activate the Fullscreen API because use of the Fullscreen API requires User Interaction.

It is possible to simulate User Interaction with sendEvent in PhantomJS, but other browsers will require an some sort of event handler. I haven't found a way to tell the browser that it's okay to allow Fullscreen API requests without User Interaction.

For my purposes, I'm just going to use an onclick handler and make the test pass and use the resulting lib for my project. However, I'm wondering what solution you'd like me to implement so that the Unit Tests are actually testing the Fullscreen API. Do you use any CI tools? Is an onclick handler acceptable? Can I simulate User Interaction with PhantomJS for the CI tests if there are any?

Thanks!

@bdougherty Brad, I understand you don't have time to continue work on this library. That's sad, but of course, it's OK Remains the question what to do with that. Would you mind to donate the library to someone else? For instance, I could step in. I'm an experienced open source developer, so I know what I'm offering. I'm offering leisure time I could use to do other things. Even so, I'd happily contribute some of my precious leisure time in order to revive your library.

If you've not ok with this, please do these two things:

• Take your online demo offline (bad solution), or add a notice that you've abandoned the library and send developers to one of the alternative that are still alive (better solution).
• Add a short notice to this GitHub project that you've abandoned the project. The readme.md is a good place for that.

Thanks in advance,
Stephan

I don't think this would be desirable, returning to the exact position on the page you were, before you entered full screen, would be much nicer.

I've noticed on my iframe content that document.webkitFullscreenEnabled is undefined when using the developer tools in Safari. Thus, using webkitFullscreenEnabled to determine if BigScreen.enabled is true will NOT work.

There may be a better way to fix it, but I would suggest just checking to see if the document.webkitIsFullScreen property exists to determine whether or not the fullscreen API is supported. Here's what I changed to the bigscreen source code to make it work properly in Safari:

Line 12: Added webkitIsFullScreen as one of the properties to check for enabled:

enabled: ['fullscreenEnabled', 'webkitFullscreenEnabled', 'mozFullScreenEnabled', 'msFullscreenEnabled', 'webkitIsFullScreen'],

Line 215: Added a check that enabled is not set to webkitIsFullScreen:

if (iframe && (document[fn.enabled] === false && fn.enabled !== "webkitIsFullScreen")) {

Under line 336, this was added:

if (fn.enabled === 'webkitIsFullScreen'){ return true; }

I've also attached my version to this post. Maybe there is a better way to check for fullscreen support in Safari. BigScreen.enabled should be true for me because 5.1.x does support it, but the document doesn't always have the webkitFullscreenEnabled property. It can be undefined (in my case with iframe content) which means BigScreen will incorrectly say that it does NOT support fullscreen when it does.
bigscreen_modified_safari_detection.zip

It only checks for the one it knows about called explicitly through request(), but it's possible for a <video> to enter fullscreen automatically when it starts (for example, on the iPhone).

I think the best way is to select all videos when element is called and check each one. That means document[fn.element] should be checked first to avoid unnecessary DOM interaction.