Webkit setting for embedders that do not support fullscreen.

Source/core/frame/Settings.in

 # Defines properties which are available on the Settings object.
 #
 # Please think carefully before adding a new Setting.  Some questions to
 # consider are:
 # - Should this be a RuntimeEnabledFeature instead? Settings are for things
 #   which we support either values of at runtime.  Features are set at renderer
 #   process startup and are never changed. Features also tend to be set to a
 #   value based on the platform or the stability of the code in question, where
 #   as settings both codepaths need to be stable.
 # - How will you ensure test coverage of all relevant values of your setting?
@@ skipping 251 matching lines @@
 
 # This value indicates the maximum number of bytes a document is allowed
 # to transmit in Beacons (via navigator.sendBeacon()) -- Beacons are
 # intended to be smaller payloads transmitted as a page is unloading, not
 # a general (one-way) network transmission API.
 # The spec ( https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html )
 # does not proscribe an upper limit, but allows for it -- the underlying
 # API will return 'false' in that case.
 maxBeaconTransmission type=int, initial=16384
 
+# The following two settings are only exposed for Layout Tests.

[philipj_slow, 2014/07/30 12:11:18]

That's not quite true, they're intended to be set by Android WebView...

[Ignacio Solla, 2014/07/30 14:40:00]

Added "only exposed through Javascript".

[philipj_slow, 2014/07/30 15:47:17]

All settings are exposed in internals.settings for LayoutTests. These settings
seem like most, intended to be set by Chromium, it would be helpful to instead
describe what they do. It sounds like this one would disable the Fullscreen API
entirely, which isn't quite the case.

[Ignacio Solla, 2014/07/31 10:30:51]

Oh, I see, thanks for the clarification!

I have added descriptions now.

+fullscreenEnabled initial=true
+# FIXME: This is a temporary flag and should be removed once

[philipj_slow, 2014/07/30 12:11:18]

Can that ever actually happen. Won't there continue to be apps that don't
implement WebChromeClient.onShowCustomView?

[Ignacio Solla, 2014/07/30 14:40:00]

The fullscreenEnabled setting is for apps that do not implement
onShowCustomView.

The disallowFullscreenForNonMediaElements is for a limitation in the framework.
It will always be true in the WebView (well, until we add support for non-media
elements). The we will have fullscreen for non-media elements unless the app
does not implement onShowCustomView.

[philipj_slow, 2014/07/30 15:47:17]

Let's see if I understand.

http://developer.android.com/reference/android/webkit/WebView.html says "In
order to support inline HTML5 video in your application, you need to have
hardware acceleration turned on, and set a WebChromeClient. For full screen
support, implementations of onShowCustomView(View,
WebChromeClient.CustomViewCallback) and onHideCustomView() are required,
getVideoLoadingProgressView() is optional."

In other words, if onShowCustomView isn't implemented, no fullscreen will work
at all, video or otherwise.

When onShowCustomView is implemented, non-video fullscreen still never works,
but this is something you hope to eventually fix.

Is that right? If so I understand why two settings are needed.

[Ignacio Solla, 2014/07/31 10:30:51]

Exactly, your understanding is correct.

+# the Android WebView supports fullscreen for non-media elements
+# (crbug.com/398485).
+disallowFullscreenForNonMediaElements initial=false