Using JNI() forbids us to use AutoLocalJNIFrame if the method isn't called in the main thread. We should use JNIForThread() instead to allow such usage.

Who is using JNI on another thread?

(In reply to Michael Wu [:mwu] from comment #1) > Who is using JNI on another thread? All callers of GetJNIForThread() could use JNI on another thread (which I realize is mostly WebSMS methods). However, I wrote a method that is called from another thread which means I can't call it with the current implementation of AutoLocalJNIFrame.

related to bug 704785?

(In reply to Naoki Hirata :nhirata from comment #3) > related to bug 704785? The stack track lets me think the crash in bug 704785 happens in the main thread. In that case, it wouldn't be related.

Comment on attachment 577014 [details] [diff] [review] Patch v1 I don't want AutoLocalJNIFrame (with JNIForThread) to be used by other threads unless the code explicitly asks for it. In most cases, getting a JNIEnv on a different thread isn't a good idea unless you really need it and have made sure that it is safe.

Comment on attachment 577621 [details] [diff] [review] Patch v3 Review of attachment 577621 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, thanks! ::: widget/src/android/AndroidBridge.h @@ +253,5 @@ > // the AutoLocalJNIFrame's scope INVALID; be sure that you locked down > // any local refs that you need to keep around in global refs! > void Purge() { > + mJNIEnv->PopLocalFrame(NULL); > + mJNIEnv->PushLocalFrame(mEntries); You can probably use Push() here too.