[Android WebView] Convert context menu callback to long press

android_webview/native/aw_web_contents_view_delegate.h

+// Copyright (c) 2012 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 ANDROID_WEBVIEW_NATIVE_AW_WEB_CONTENTS_VIEW_DELEGATE_H_
+#define ANDROID_WEBVIEW_NATIVE_AW_WEB_CONTENTS_VIEW_DELEGATE_H_
+
+#include "content/public/browser/web_contents_view_delegate.h"
+
+#include "base/android/scoped_java_ref.h"
+#include "base/compiler_specific.h"
+
+namespace content {
+class WebContents;
+}  // namespace content
+
+namespace android_webview {
+
+class AwContents;
+
+// This class is only used to create context menus on Android.
+class AwWebContentsViewDelegate : public content::WebContentsViewDelegate {
+ public:
+  AwWebContentsViewDelegate(content::WebContents* web_contents);
+  virtual ~AwWebContentsViewDelegate();
+
+  // content::WebContentsViewDelegate implementation.
+  virtual content::WebDragDestDelegate* GetDragDestDelegate() OVERRIDE;
+  virtual void ShowContextMenu(
+      const content::ContextMenuParams& params,
+      content::ContextMenuSourceType type) OVERRIDE;
+
+ private:
+  // Weak pointer due to ownership graph:
+  // WebContents->WebContentsView->this.
+  content::WebContents* web_contents_;
+
+  base::android::ScopedJavaGlobalRef<jobject> web_contents_view_delegate_;

[joth, 2012/12/11 01:22:11]

ah. hmm. this maybe a problem: this will stop the java side getting GC'd so long
as the native object exists. Snag is the java side object holds a ref to the
ViewGroup instance, which will stop the WebView being GC'ed, and hence the
WebContents would never get deleted. leak.

Solution: use a weak ref here, and have a java-side object (AwContents, if no
one else) hold a ref to the AwWebContentsViewDelegate java instance to keep in
valid in memory, which the GC can then correctly spot unreachable cycles
through.

(Generalized rule: always use a weak ref from c++ to java unless you know for
sure you shouldn't)

[boliu, 2012/12/11 02:25:33]

That dependency graph feels weird...does this work?:

Have java AwWebContentsViewDelegate hold a WeakReference<ViewGroup> instead?
Then we still have the native owns java, but don't have the dependency that
prevents gc?

[joth, 2012/12/11 02:37:39]

yeah, it feels weird -- par for the course in mixing GCed and non-GCed languages
it seems...

do you have evidence it won't work?
Experience is, this is a loosing battle: you'll need a and a Bad-Ass comment on
AwWebContentsViewDelegate.java explaining why it's only holding WeakRefs and why
new references must be too, but still some new weird case will come up (some one
subclasses it? Someone makes an anon inner class bound to both the outer class
and to something else?) that thwarts the GC anyway.

so, yeah, we're moving to a point where all the native objects are owned by
WebContents, all java objects held valid (indirectly) by the WebView instance,
and there's a single point that has finalizer to cleanup the WebContents (and
it's tree of objects) when the java-side web disappear. 

+
+  DISALLOW_COPY_AND_ASSIGN(AwWebContentsViewDelegate);
+};
+
+bool RegisterAwWebContentsViewDelegate(JNIEnv* env);
+
+}  // namespace android_webview
+
+
+#endif  // ANDROID_WEBVIEW_NATIVE_AW_WEB_CONTENTS_VIEW_DELEGATE_H_