Support setting mouse cursor icon in Android N.

chrome/android/java/src/org/chromium/chrome/browser/coordinator/CoordinatorLayoutForPointer.java

+// Copyright 2017 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.
+
+package org.chromium.chrome.browser.coordinator;
+
+import android.content.Context;
+import android.os.Build;
+import android.support.design.widget.CoordinatorLayout;
+import android.util.AttributeSet;
+import android.view.MotionEvent;
+import android.view.PointerIcon;
+
+/**
+ * This class extends a {@link CoordinatorLayout} which is the parent of

[Ted C, 2017/07/21 00:15:25]

wrap comments at 100 chars in java land

[jaebaek, 2017/07/21 10:03:04]

Done.

+ * {@link CompositorViewHolder} in Android view hierarchy. The main
+ * purpose of this class is to correctly determine the pointer icon that
+ * must be applied according to a mouse motion event.

[mdjones, 2017/07/20 21:49:06]

nit: Mention this is needed because the default android impl does not consider
view visibility.

[jaebaek, 2017/07/21 10:03:04]

Done.

+ */
+public class CoordinatorLayoutForPointer extends CoordinatorLayout {
+    public CoordinatorLayoutForPointer(Context context) {

[Ted C, 2017/07/21 00:15:25]

we should only need the second constructor for inflating from xml, so let's
remove this one

[jaebaek, 2017/07/21 10:03:04]

Done.

+        super(context);
+    }
+
+    public CoordinatorLayoutForPointer(Context context, AttributeSet attrs) {
+        super(context, attrs);
+    }
+
+    @Override
+    public PointerIcon onResolvePointerIcon(MotionEvent event, int pointerIndex) {

[Ted C, 2017/07/21 00:15:25]

I believe this got fixed in N-MR1 (b/34114031).

Should we only do this on N and otherwise call super.onResolvePointerIcon?

[jaebaek, 2017/07/21 10:03:04]

I want to check the updated code, but I cannot access it.
Based on the description, I am not sure they handle the
case the view is partially visible. Why don't we keep
this? I guess calling onResolvePointerIcon for each child
does not cause that big performance overhead.

+        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.N) return null;
+
+        final int childrenCount = getChildCount();
+        for (int i = childrenCount - 1; i >= 0; --i) {
+            if (getChildAt(i).getVisibility() != VISIBLE) continue;
+            PointerIcon icon = getChildAt(i).onResolvePointerIcon(event, pointerIndex);

[Ted C, 2017/07/21 18:45:31]

this doesn't actually check that the mouse cursor is within the bounds
of the view.  Doesn't that mean that the first visible child will always
use their pointer?

In general, I think this logic should mimic as much if not all of the
existing platform code, it should just add the missing visibility check.

[mdjones, 2017/07/21 20:42:28]

With the assumption that this layout is always match_parent, this actually ends
up working (the bounds checks are only needed in the children). Though, I do
agree we should probably just take the ViewGroup implementation and expand on
it.

[jaebaek, 2017/07/24 07:34:11]

Ah .. it's my mistake. I added bound check here. I also dropped this null check.
This method only checks the visibility and I adjusted heights of bottom
containers (i.e., @+id/bottom_sheet_snackbar_container and @+id/bottom_container
in main.xml) as wrap_content.

+            if (icon != null) return icon;
+        }
+        return null;
+    }
+}