Don't show video fullscreen until DidEnterFullscreen() is called, and disable fullscreen for non-me…

Don't show video fullscreen until DidEnterFullscreen() is called, and disable fullscreen for non-media elements for android webview

This change is copied from https://codereview.chromium.org/284913002/
However, the previous change breaks android webview because android webview doesn't support fullscreen except media.
AwWebContentsDelegate::ToggleFullscreenModeForTab is actually not implemented in webview.
To solve the webview issue, this change adds a flag to disallow elements other than video to enter fullscreen.
When this flag is enabled, webview will only respond to fullscreen calls from the video element and can thus send the resize IPC to complete the will/didEnterfullscreen call.

BUG=367346
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177458

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177626

[qinmin, 2014-05-16 20:40:46]

PTAL

[aelias_OOO_until_Jul13, 2014-05-17 00:02:13]

There was some talk earlier about Android WebView support HTML-based media
controls/subtitles by creating a special SurfaceView, did that end up happening
yet?  If so, could we just extend that SurfaceView mode to support
enterFullscreen on any element?  Then we would avoid this ugly setting.

[qinmin, 2014-05-17 01:33:52]

On 2014/05/17 00:02:13, aelias wrote:
> There was some talk earlier about Android WebView support HTML-based media
> controls/subtitles by creating a special SurfaceView, did that end up
happening
> yet?  If so, could we just extend that SurfaceView mode to support
> enterFullscreen on any element?  Then we would avoid this ugly setting.

No, that's not ready yet. Even if Android webview supports html-based media
controls, it won't support fullscreen api on other elements.

[aelias_OOO_until_Jul13, 2014-05-19 23:53:56]

lgtm, over to abarth@ for Source/public OWNERS.

This setting is pretty ugly.  But I chatted offline with Min and it's not
obvious other approaches are less ugly.  So I guess we can land to fix the bug.

Ideally, WebView would just support fullscreen API in general and then we could
get rid of this complexity.  Ignatio, my understanding is that you're working to
add custom media control support to WebView by providing a tree of two
SurfaceViews to onShowCustomView.  It seems like once you've achieved this, it
should be mostly trivial to support general-purpose enterFullscreen (just do the
same thing, without the video underneath).  Could you expand the scope of your
work to do that?

[Ignacio Solla, 2014-05-20 09:17:44]

On 2014/05/19 23:53:56, aelias wrote:
> lgtm, over to abarth@ for Source/public OWNERS.
> 
> This setting is pretty ugly.  But I chatted offline with Min and it's not
> obvious other approaches are less ugly.  So I guess we can land to fix the
bug.
> 
> Ideally, WebView would just support fullscreen API in general and then we
could
> get rid of this complexity.  Ignatio, my understanding is that you're working
to
> add custom media control support to WebView by providing a tree of two
> SurfaceViews to onShowCustomView.  It seems like once you've achieved this, it
> should be mostly trivial to support general-purpose enterFullscreen (just do
the
> same thing, without the video underneath).  Could you expand the scope of your
> work to do that?

Initially I'm just focusing on fullscreen video, and later I will expand the
solution
to non-video elements. The timelines are still not clear so please go ahead with
this patch.

We're now exploring the possibility of sending delegated frame data from the
original
WebView to a new FullscreenView.

Previously I had prototyped the solution that you described, ie. creating a tree
with the 
ContentVideoView and a new FullscreenView, and then moving the WebContents from
the
original WebView to the FullscreenView while in fullscreen.

[qinmin, 2014-05-21 21:06:33]

ping! abarth@, would you please take a look?

[qinmin, 2014-05-21 21:09:39]

dglazkov＠, would you please take a look at public/web/?

[qinmin, 2014-05-27 16:14:42]

On 2014/05/21 21:09:39, qinmin wrote:
> dglazkov＠, would you please take a look at public/web/?

ping, dglazkov@, would you please take a look?

[dglazkov, 2014-05-27 16:35:37]

lgtm.

[qinmin, 2014-07-03 05:10:32]

The CQ bit was checked by qinmin@chromium.org

[commit-bot: I haz the power, 2014-07-03 05:11:02]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/qinmin@chromium.org/290643005/40001

[commit-bot: I haz the power, 2014-07-03 07:45:06]

Change committed as 177458

[Stephen White, 2014-07-04 02:00:01]

On 2014/07/03 07:45:06, I haz the power (commit-bot) wrote:
> Change committed as 177458

Sorry, this still seems to be breaking android_webview_instrumentation_tests on
Android Tests (dbg):

http://build.chromium.org/p/chromium.webkit/builders/Android%20Tests%20(dbg)/...

[FAIL]
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest#testGetVideoLoadingProgressView:
C  390.892s Main  java.util.concurrent.TimeoutException: waitForCallback timed
out!
C  390.892s Main  	at
org.chromium.content.browser.test.util.CallbackHelper.waitForCallback(CallbackHelper.java:183)
C  390.892s Main  	at
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest.waitForViewAttached(AwContentsClientGetVideoLoadingProgressViewTest.java:44)
C  390.892s Main  	at
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest.testGetVideoLoadingProgressView(AwContentsClientGetVideoLoadingProgressViewTest.java:74)
C  390.892s Main  	at java.lang.reflect.Method.invokeNative(Native Method)
C  390.892s Main  	at
android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
C  390.892s Main  	at
android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:199)
C  390.892s Main  	at
android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:192)
C  390.892s Main  	at
android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
C  390.892s Main  	at
android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
C  390.892s Main  	at
android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:554)
C  390.892s Main  	at
android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1701)

[qinmin, 2014-07-04 02:29:42]

On 2014/07/04 02:00:01, Stephen White wrote:
> On 2014/07/03 07:45:06, I haz the power (commit-bot) wrote:
> > Change committed as 177458
> 
> Sorry, this still seems to be breaking android_webview_instrumentation_tests
on
> Android Tests (dbg):
> 
>
http://build.chromium.org/p/chromium.webkit/builders/Android%20Tests%20(dbg)/...
> 
> [FAIL]
>
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest#testGetVideoLoadingProgressView:
> C  390.892s Main  java.util.concurrent.TimeoutException: waitForCallback timed
> out!
> C  390.892s Main  	at
>
org.chromium.content.browser.test.util.CallbackHelper.waitForCallback(CallbackHelper.java:183)
> C  390.892s Main  	at
>
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest.waitForViewAttached(AwContentsClientGetVideoLoadingProgressViewTest.java:44)
> C  390.892s Main  	at
>
org.chromium.android_webview.test.AwContentsClientGetVideoLoadingProgressViewTest.testGetVideoLoadingProgressView(AwContentsClientGetVideoLoadingProgressViewTest.java:74)
> C  390.892s Main  	at java.lang.reflect.Method.invokeNative(Native Method)
> C  390.892s Main  	at
>
android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
> C  390.892s Main  	at
> android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:199)
> C  390.892s Main  	at
>
android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:192)
> C  390.892s Main  	at
> android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
> C  390.892s Main  	at
> android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
> C  390.892s Main  	at
>
android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:554)
> C  390.892s Main  	at
>
android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1701)

hmm... need to disable that test too until
https://codereview.chromium.org/292573004/ lands

[qinmin, 2014-07-08 02:10:30]

The CQ bit was checked by qinmin@chromium.org

[commit-bot: I haz the power, 2014-07-08 02:11:08]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/qinmin@chromium.org/290643005/40001

[commit-bot: I haz the power, 2014-07-08 02:11:40]

Change committed as 177626