Resume cursor blinking on closing context menu

chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java

Index: chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java b/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
index f7b81e33a5ac0d72a474a8eaf8448b36811abc9c..b3e4971139b69ad9d7d9eacf3d25bb26d12a7dda 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/ChromeActivity.java
@@ -128,6 +128,7 @@ import org.chromium.content.browser.ContentViewCore;
 import org.chromium.content.common.ContentSwitches;
 import org.chromium.content_public.browser.ContentBitmapCallback;
 import org.chromium.content_public.browser.LoadUrlParams;
+import org.chromium.content_public.browser.WebContents;
 import org.chromium.content_public.browser.readback_types.ReadbackResponse;
 import org.chromium.policy.CombinedPolicyProvider.PolicyChangeListener;
 import org.chromium.printing.PrintManagerDelegateImpl;
@@ -1583,6 +1584,15 @@ public abstract class ChromeActivity extends AsyncInitializationActivity
         }
     }
 
+    @Override
+    public void onContextMenuClosed(Menu menu) {

[no sievers, 2015/11/30 21:25:00]

I can't find where this is overriden from.

[Ted C, 2015/11/30 21:30:49]

Hmm...it is sad that we have to add this at this high of a level, but you can't
add a dismiss listener on the Menu during construction, so I think this will
have to do.

Alternatively, you could listen for a combination of window focus/window
visibility at the view level and gather the same amount of information.  I would
assume you'd lose focus when showing the context menu and either gain it back or
lose visibility entirely depending on the user action.

[Changwan Ryu, 2015/12/01 05:54:01]

This overrides Activity#onContextMenuClosed. Added javadoc.

[Changwan Ryu, 2015/12/01 05:54:01]

Hmm.. I considered it, but if context menu opens yet another view, then
depending on the timing the original view may not get window focus or visibility
at the right timing (because it was already lost when context menu pops up), and
the callback will only be called when the user comes back to the original view.
Then the timing of callback may be a bit off, although I cannot think of any
disastrous scenario out of it, but I'm afraid that it might introduce
inconsistency of behavior.

+        final Tab currentTab = getActivityTab();
+        if (currentTab == null) return;
+        WebContents webContents = currentTab.getWebContents();
+        if (webContents == null) return;
+        webContents.onContextMenuClosed();

[Ted C, 2015/11/30 21:30:49]

What happens if the web contents was not the thing that triggered the context
menu?  Could we be incorrectly causing the cursor to blink if something else
triggered one (or does it track whether it was in fact showing a context menu)?

Also, WebView does not have a ChromeActivity, so if you need this to be called
then this will not work like this.

[Changwan Ryu, 2015/12/01 05:54:01]

Good point! I've added WebContents#onContextMenuOpened() to prevent this case.
Since there can be only one context menu at a time, we won't get context menu
callbacks from other places.
AwWebContentsViewDelegate does not trigger ContextMenuHelper, so we won't have
this problem.

+    }
+
     private void enableHardwareAcceleration() {
         // HW acceleration is disabled in the manifest. Enable it only on high-end devices.
         if (!SysUtils.isLowEndDevice()) {