Chris, one of the reasons Chrome does not support fullscreen API is security concern (what if the page render Chrome toolbar to perform URL spoofing). Now after Android supports fullscreen API, should we reconsider the constraints for iOS?

A quick correction to my previous statement: Android Chrome does not lock orientation by default; it requires a call to screen.orientation.lock('landscape') after going fullscreen.

Also, a quick internal note: https://docs.google.com/document/d/1xm7f_GRvX2Nn-t74wOVbxIgOCsIt9ObrkATGRnC9Oes/edit

palmer: do you have any specific security concerns about iOS implementing the fullscreen API?

As long as the iOS implementation uses the same mechanisms to enter and leave fullscreen mode as the Android implementation, it's fine by me. The Android implementation was heavily discussed and vetted, and we are OK with it.

We going to revisit this feature in the next quarter.

Hello,
Has there been any progress on this feature? Thank you!

Sorry, unfortunately /ios/web team does not have bandwidth to work on this any time soon. pinkerton@, is this something that other folks from iOS team can do?

+rbyers 

Presumably this is something Rick's team should be owning, especially as it goes to implementing web APIs. 

I'm still concerned about the "swipe down from the top" gesture to get out of this mode since iOS has reserved that gesture already. We'd have to come up with something else (swipe up from bottom is also reserved). 

At the moment we're generally not adding new web APIs to Chrome for iOS unless there is a compelling strategic reason to do so (since our options for doing so are very limited given the appstore policy on iOS).  Maybe there's such an argument for fullscreen, I don't know.  foolip/dknox, any thoughts?

What currently happens if you visit youtube.com on Chrome for iOS? Does it only play inline, or does it always go into the special fullscreen mode for video that iOS has?

Supporting Fullscreen per https://fullscreen.spec.whatwg.org/ without making any changes to the engine would be quite challenging I think, but it depends on what native APIs are available I suppose.

iOS system video player supports inline and fullscreen videos and I believe YouTube uses that system video player.

I see. Just to spell out the things that I think would be the hardest to get right if implementing the Fullscreen API as a polyfill-like thing, even with internals:

* The rendering, where lots of CSS properties need to be overwritten with !important in order to trump things that the page happens to set.
* The :-webkit-full-screen and :fullscreen pseudo-class, which site CSS will use.
* The timing of the the rendering should change and events be fired, although it's likely that some small differences here would not be breaking.

Dropping "HTML" from title since it's not part of HTML.

It looks like WebKit will include support for Fullscreen: https://bugs.webkit.org/show_bug.cgi?id=178924

I looked into the patch a little bit and it seems like this will occur out of our control.  The implementation of WKWindowFullscreenController has the following couple lines in |-enterFullScreen|:

+    _viewControllerForPresentation = [UIViewController _viewControllerForFullScreenPresentationFromView:_webView];
+    _fullscreenViewController = adoptNS([[_WKFullScreenViewController alloc] init]);
+    [_fullscreenViewController setTransitioningDelegate:self];
+    [_fullscreenViewController setModalPresentationStyle:UIModalPresentationCustom];
+    [_fullscreenViewController setTarget:self action:@selector(requestExitFullScreen)];

Seems like WebKit is using private UIViewController API to choose a parent to present upon.  It's likely just walking the UIViewController hierarchy to find the top-most presented view controller that defines its own presentation context, but we'll have to dig into it to figure out exactly which view controller is being used, as this will likely be necessary to dismiss fullscreen for browser or app lifecycle events.