AndroidOverlay implementation using Dialog.

content/browser/android/dialog_overlay_impl.h

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_BROWSER_ANDROID_DIALOG_OVERLAY_IMPL_H_
+#define CONTENT_BROWSER_ANDROID_DIALOG_OVERLAY_IMPL_H_
+
+#include "base/android/jni_android.h"
+#include "base/android/scoped_java_ref.h"
+#include "base/unguessable_token.h"
+#include "content/browser/android/content_view_core_impl.h"
+#include "content/browser/android/content_view_core_impl_observer.h"
+
+namespace content {
+
+// Native counterpart to DialogOverlayImpl java class.  This is created by the
+// java side.  When the ContentViewCore for the provided token is attached or
+// detached from a WindowAndroid, we get the Android window token and notify the
+// java side.
+class DialogOverlayImpl : public ContentViewCoreImplObserver {
+ public:
+  // Registers the JNI methods for DialogOverlayImpl.
+  static bool RegisterDialogOverlayImpl(JNIEnv* env);
+
+  DialogOverlayImpl(const base::android::JavaParamRef<jobject>& receiver,
+                    const base::UnguessableToken& token);
+
+  ~DialogOverlayImpl() override;
+
+  // ContentViewCoreImplObserver
+  void OnContentViewCoreDestroyed() override;
+  void OnAttachedToWindow() override;
+  void OnDetachedFromWindow() override;
+
+  // Unregister for tokens if we're registered, and clear |cvc_|.
+  void UnregisterForTokensIfNeeded();
+
+ private:
+  // Look up the ContentViewCore for |renderer_pid_| and |render_frame_id_|.
+  ContentViewCoreImpl* GetContentViewCore();
+
+ private:

[boliu, 2017/04/26 00:19:08]

nit: no need for double private

[liberato (no reviews please), 2017/04/26 17:26:34]

Done.

+  // Java object that owns us.
+  base::android::ScopedJavaGlobalRef<jobject> receiver_;

[boliu, 2017/04/26 00:19:08]

the convention is to call this obj_, when native and java classes have the same
name, and roughly share the same lifetime

also.. I *think* this should be a JavaObjectWeakGlobalRef:
Every strong reference in native is a gc root to the garbage collector. So this
reference means that the context, and transitively the entire view tree will be
prevented from being gc-ed. But webview in particular relies on gc to collect
itself, so this would cause a leak, unless something guarantees DialogOverlays
are always dismissed.

The simple fix is use JavaObjectWeakGlobalRef. native is entirely owned by java
side, so shouldn't be a problem. Java side is kept alive by mojo, so I don't
think it's actually relying on this ref. Just need a null check after every
dereference, you can look at ContentViewCore as an example.

Alternative is to the ref be destroyed OnDetachedFromWindow (and created in
OnAttachedToWindow), which doesn't really work unless the observer is in java
code. So I guess JavaObjectWeakGlobalRef it is then..

[liberato (no reviews please), 2017/04/26 17:26:34]

done.

however, now i'm worried about the webview GC cleanup path.  if the java object
is finalized without a DialogOverlayImpl.cleanup() call, then it'll leak the
native side.

i suppose that i can |delete this| on a failed weak ref promotion, but that
seems a little hacky.

do you know if holding a native mojo client, which in turn has a mojo binding to
the DialogOverlayImpl java object, is enough to prevent GC?  i'm worried about
what happens if whatever mojo magic exists in java is shut down before AVDA is
destroyed.

[boliu, 2017/04/26 17:40:11]

I would certainly hope so, but that's a question for mojo folks..

+
+  base::UnguessableToken token_;
+
+  // ContentViewCoreImpl instance that we're registered with as an observer.
+  ContentViewCoreImpl* cvc_;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_ANDROID_DIALOG_OVERLAY_IMPL_H_