Cache proxy view return value to avoid deadlock

Cache proxy view return value to avoid deadlock

If WebView has an active IME but the Android app calls
InputMethodManager#hideSoftInputFromWindow() on a non-UI thread,
then a deadlock may happen.

One example case is when JavaScript triggers it through JavascriptInterface
(therefore, on JavaBridge thread.)

The deadlock scenario is as follows:

1) InputMethodManager#hideSoftFromWindow() calls
   ThreadedInputConnectionProxyView#getWindowToken() on JavaBridge thread
   while holding InputMethodManager#mH.
   Then getWindowToken() waits for UI thread to become available.
2) At almost same time, InputMethodManager#restartInput() was waiting for
   InputMethodManager#mH on UI thread

This deadlock can be avoided by caching return values as atomic objects.

Alternative approach I've tried: check the current thread and block
it only when it's IME thread - this may still leave room for deadlock
between IME thread and UI thread.

BUG=630937
Review-Url: https://codereview.chromium.org/2175263002
Cr-Commit-Position: refs/heads/master@{#408925}
(cherry picked from commit 43ceb11f9abf67fea18e8a731a9ef61f5cfe22fc)

Committed: https://chromium.googlesource.com/chromium/src/+/28ceae2df36aa9368b2a04179ce23a03d44ea328

[Changwan Ryu, 2016-08-01 08:32:31]

Description was changed from

==========
Cache proxy view return value to avoid deadlock

If WebView has an active IME but the Android app calls
InputMethodManager#hideSoftInputFromWindow() on a non-UI thread,
then a deadlock may happen.

One example case is when JavaScript triggers it through JavascriptInterface
(therefore, on JavaBridge thread.)

The deadlock scenario is as follows:

1) InputMethodManager#hideSoftFromWindow() calls
   ThreadedInputConnectionProxyView#getWindowToken() on JavaBridge thread
   while holding InputMethodManager#mH.
   Then getWindowToken() waits for UI thread to become available.
2) At almost same time, InputMethodManager#restartInput() was waiting for
   InputMethodManager#mH on UI thread

This deadlock can be avoided by caching return values as atomic objects.

Alternative approach I've tried: check the current thread and block
it only when it's IME thread - this may still leave room for deadlock
between IME thread and UI thread.

BUG=630937

Review-Url: https://codereview.chromium.org/2175263002
Cr-Commit-Position: refs/heads/master@{#408925}
(cherry picked from commit 43ceb11f9abf67fea18e8a731a9ef61f5cfe22fc)
==========

to

==========
Cache proxy view return value to avoid deadlock

If WebView has an active IME but the Android app calls
InputMethodManager#hideSoftInputFromWindow() on a non-UI thread,
then a deadlock may happen.

One example case is when JavaScript triggers it through JavascriptInterface
(therefore, on JavaBridge thread.)

The deadlock scenario is as follows:

1) InputMethodManager#hideSoftFromWindow() calls
   ThreadedInputConnectionProxyView#getWindowToken() on JavaBridge thread
   while holding InputMethodManager#mH.
   Then getWindowToken() waits for UI thread to become available.
2) At almost same time, InputMethodManager#restartInput() was waiting for
   InputMethodManager#mH on UI thread

This deadlock can be avoided by caching return values as atomic objects.

Alternative approach I've tried: check the current thread and block
it only when it's IME thread - this may still leave room for deadlock
between IME thread and UI thread.

BUG=630937

Review-Url: https://codereview.chromium.org/2175263002
Cr-Commit-Position: refs/heads/master@{#408925}
(cherry picked from commit 43ceb11f9abf67fea18e8a731a9ef61f5cfe22fc)

Committed:
https://chromium.googlesource.com/chromium/src/+/28ceae2df36aa9368b2a04179ce2...
==========

[Changwan Ryu, 2016-08-01 08:32:33]

Committed patchset #1 (id:1) manually as
28ceae2df36aa9368b2a04179ce23a03d44ea328.