Check null for WebViewCore's nativeClass before calling

back to Java. This may happen if WebKit holds some reference
of the Document even when our Java side has been destroyed.
So when Document finally is deleted, the call back to Java
will have null nativeClass.

In the long run, we may need to add the check for all the
callback to Java.

Fix http://b/issue?id=2148023

1 files changed, 7 insertions, 2 deletions

diff --git a/WebKit/android/jni/WebViewCore.cpp b/WebKit/android/jni/WebViewCore.cpp
index 7ab598c..1cf96d5 100644
--- a/WebKit/android/jni/WebViewCore.cpp
+++ b/WebKit/android/jni/WebViewCore.cpp
@@ -903,8 +903,13 @@ void WebViewCore::needTouchEvents(bool need)
 
 #if ENABLE(TOUCH_EVENTS) // Android
     JNIEnv* env = JSC::Bindings::getJNIEnv();
-    env->CallVoidMethod(m_javaGlue->object(env).get(), m_javaGlue->m_needTouchEvents, need);
-    checkException(env);
+    AutoJObject obj = m_javaGlue->object(env);
+    // if this is called after DESTROY is handled in WebViewCore.java, mNativeClass
+    // will be null. Do nothing.
+    if (env && obj.get()) {
+        env->CallVoidMethod(obj.get(), m_javaGlue->m_needTouchEvents, need);
+        checkException(env);
+    }
 #endif
 }