Implement clearView to match classic

android_webview/java/src/org/chromium/android_webview/AwContents.java

Index: android_webview/java/src/org/chromium/android_webview/AwContents.java
diff --git a/android_webview/java/src/org/chromium/android_webview/AwContents.java b/android_webview/java/src/org/chromium/android_webview/AwContents.java
index 1e7f88d16b5d9c8dba1c7717085b88bfbb4c9ad1..98a6b2a9b7400d932d4fbc877ac7e89490a0fcb5 100644
--- a/android_webview/java/src/org/chromium/android_webview/AwContents.java
+++ b/android_webview/java/src/org/chromium/android_webview/AwContents.java
@@ -180,6 +180,9 @@ public class AwContents {
     private boolean mContainerViewFocused;
     private boolean mWindowFocused;
 
+    private boolean mClearViewActive;
+    private boolean mPictureListenerEnabled;
+
     private AwAutofillManagerDelegate mAwAutofillManagerDelegate;
 
     private static final class DestroyRunnable implements Runnable {
@@ -694,12 +697,14 @@ public class AwContents {
         }
 
         mScrollOffsetManager.syncScrollOffsetFromOnDraw();
-
         canvas.getClipBounds(mClipBoundsTemporary);
-        if (!nativeOnDraw(mNativeAwContents, canvas, canvas.isHardwareAccelerated(),
-                    mContainerView.getScrollX(), mContainerView.getScrollY(),
-                    mClipBoundsTemporary.left, mClipBoundsTemporary.top,
-                    mClipBoundsTemporary.right, mClipBoundsTemporary.bottom)) {
+
+        if (mClearViewActive) {
+            canvas.drawColor(getEffectiveBackgroundColor());

[boliu, 2013/09/20 20:55:49]

Documentation says draws white background, not whatever was set by app. We
should do what it does, not what it says, did you double check what old webview
did?

[Kristian Monsen, 2013/09/20 21:15:17]

Classic actually does the background color as well. This is just insane. Oh
well.

+        } else if (!nativeOnDraw(mNativeAwContents, canvas, canvas.isHardwareAccelerated(),
+                mContainerView.getScrollX(), mContainerView.getScrollY(),
+                mClipBoundsTemporary.left, mClipBoundsTemporary.top,
+                mClipBoundsTemporary.right, mClipBoundsTemporary.bottom)) {
             Log.w(TAG, "nativeOnDraw failed; clearing to background color.");
             canvas.drawColor(getEffectiveBackgroundColor());
         }
@@ -729,6 +734,12 @@ public class AwContents {
                     mScrollOffsetManager.computeVerticalScrollRange()));
     }
 
+    public void clearView() {
+        mClearViewActive = true;
+        syncOnNewPictureStateToNative();
+        mContainerView.invalidate();

[boliu, 2013/08/16 23:04:55]

Is this invalidate needed? Documentation only says next onDraw, doesn't say that
this has to cause a redraw.

Documentation also mentions something about onMeasure, but doesn't matter much
there.

Also should use postInvalidateOnAnimation lest we break ics upstream.

[Kristian Monsen, 2013/09/20 19:35:56]

The behavior we are trying to match is pretty much a direct redraw.

This works at least :-)

+    }
+
     /**
      * Enable the onNewPicture callback.
      * @param enabled Flag to enable the callback.
@@ -745,7 +756,12 @@ public class AwContents {
                 }
             };
         }
-        nativeEnableOnNewPicture(mNativeAwContents, enabled);
+        mPictureListenerEnabled = enabled;
+        syncOnNewPictureStateToNative();
+    }
+
+    private void syncOnNewPictureStateToNative() {
+        nativeEnableOnNewPicture(mNativeAwContents, mPictureListenerEnabled || mClearViewActive);
     }
 
     public void findAllAsync(String searchString) {
@@ -1685,6 +1701,13 @@ public class AwContents {
 
     @CalledByNative
     public void onNewPicture() {
+        // Clear up any results from a previous clearView call
+        if (mClearViewActive) {
+            mClearViewActive = false;
+            mContainerView.invalidate();

[boliu, 2013/08/16 23:04:55]

Again is this needed? If cc activates, it should send invalidate pretty quickly
after that already.

[Kristian Monsen, 2013/09/20 19:35:56]

I think it is safe to keep it in? Remember this is very rarely called, so I
don't think we need to worry about performance concerns.

+            syncOnNewPictureStateToNative();
+        }
+
         // Don't call capturePicture() here but instead defer it until the posted task runs within
         // the callback helper, to avoid doubling back into the renderer compositor in the middle
         // of the notification it is sending up to here.