Support setting mouse cursor icon in Android N.

chrome/android/java/res/layout/main.xml

Index: chrome/android/java/res/layout/main.xml
diff --git a/chrome/android/java/res/layout/main.xml b/chrome/android/java/res/layout/main.xml
index 4d5402a867869943eb9cbe19d7be5a96224e2d81..6884914c5a72f7a8e3bf6b97191a859c48ec38df 100644
--- a/chrome/android/java/res/layout/main.xml
+++ b/chrome/android/java/res/layout/main.xml
@@ -23,12 +23,12 @@
            <FrameLayout
                 android:id="@+id/overview_list_layout_holder"
                 android:layout_width="match_parent"
-                android:layout_height="match_parent" />
+                android:layout_height="wrap_content" />

[Ted C, 2017/07/18 16:41:18]

I'm pretty sure this needs to be match_parent.  This is what shows the
accessibility tab switcher and should take up the whole screen.  That being
said, I'm not sure why it isn't marked as gone.

[jaebaek, 2017/07/19 01:18:53]

If we must keep it as match_parent, there is no chance to
set mouse cursor based on this resizing. It is mainly because
onResolvePointerIcon() of ViewGroup chooses the later
child first regardless of whether its visibility is gone or not.

https://github.com/android/platform_frameworks_base/blob/master/core/java/and...

I think we should roll it back to the way of creating a class
derived from android.support.design.widget.CoordinatorLayout
and overriding onResolvePointerIcon().

tedchoc@, mdjones@, aelias@, what is your opinion?

[mdjones, 2017/07/19 18:40:50]

This will need to remain match parent. That being said, I agree with ted that
this view should be 'gone' by default. Unfortunately, at quick glance it looks
like visibility of the view isn't considered when resolving the pointer which
makes this more difficult.

I think making a coordinator that overrides onResolvePointerIcon is probably one
of the least fragile ways to handle this. It can ignore views that are set to
'gone' (assuming I didn't miss something) and wouldn't require special logic for
each new child in this view.

[jaebaek, 2017/07/20 14:16:30]

Simply checking whether a view's visibility is 'gone'
is not enough. There are some views that are partially
visible although their visibility is 'visible' (e.g.,
BottomContainer). snackbar can be shown while other
parts of BottomContainer must be transparent. For those
transparent parts, we must choose CompositorViewHolder's
mouse cursor instead of the one of BottomContainer.

A correct way to choose mouse cursor is to find 'not
transparent' child on a given location and use its
cursor. However, I think this is redundant with the
implementation of the existing onResolvePointerIcon()
method.

A better way to reuse the existing
onResolvePointerIcon() is to choose the cursor of a
child whose onResolvePointerIcon() returns non null
value. One issue is the case a view becomes visible
but does not set a pointer icon, so the point icon
of CompositorViewHolder is chosen. To prevent this
case, I will set pointer icon for all views when
they becomes actually visible. Please review the
detail in my next code submission.

 
             <org.chromium.chrome.browser.snackbar.BottomContainer
                 android:id="@+id/bottom_container"
                 android:layout_width="match_parent"
-                android:layout_height="match_parent"
+                android:layout_height="wrap_content"
                 android:layout_gravity="start|bottom">
 
                 <HorizontalScrollView
@@ -56,7 +56,7 @@
             <org.chromium.chrome.browser.widget.FadingBackgroundView
                 android:id="@+id/fading_focus_target"
                 android:layout_width="match_parent"
-                android:layout_height="match_parent"
+                android:layout_height="0dp"

[Ted C, 2017/07/18 16:41:18]

as mentioned in the other file, this doesn't seem right.  we should be using
visibility to trigger the layout.

[jaebaek, 2017/07/19 01:18:53]

The reason behind this is because onResolvePointerIcon() of
ViewGroup chooses this instead of CompositorViewHolder
when the layout height is match_parent.

[mdjones, 2017/07/19 18:40:50]

Does this view not return null for onResolvePointerIcon? Even if
FadingBackground view consumes the whole screen, returning null should cause the
coordinator layout to check subsequent views.

                 android:layout_marginTop="@dimen/tab_strip_height"
                 android:background="@color/omnibox_focused_fading_background_color"
                 android:visibility="gone" />
@@ -92,7 +92,7 @@
            <FrameLayout
                 android:id="@+id/bottom_sheet_snackbar_container"
                 android:layout_width="match_parent"
-                android:layout_height="match_parent"
+                android:layout_height="wrap_content"
                 android:layout_gravity="start|bottom"
                 android:layout_marginTop="@dimen/bottom_nav_height_inverse" />
 
@@ -102,7 +102,6 @@
                 android:layout="@layout/empty_background_view_tablet"
                 android:layout_width="match_parent"
                 android:layout_height="match_parent" />
-
         </android.support.design.widget.CoordinatorLayout>
 
     </LinearLayout>