Unit tests will be added as a chained CL since this CL is already large.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm! thanks eleanor!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Naive question on the approach/ I don't have access to the design doc, so maybe some of the question already have answers
for (int i = childrenCount - 1; i >= 0; --i) {Not a great fan of this traversal... it seems this section is meant to update the mouse icon during drag and drop.
Since Android event dispatcher usually starts from the child, back to the parent, I wonder if you can just override the child view's `onResolvePointerIcon` that you care about?
event.setLocation(localX, localY);nit: Can you do [MotionEvent.obtain](https://developer.android.com/reference/android/view/MotionEvent#obtain(android.view.MotionEvent)) do copy the event?
for (int i = 0; i < mRecyclerView.getChildCount(); i++) {
View child = mRecyclerView.getChildAt(i);
child.setPointerIcon(icon);
}This loops through the entire RecyclerView when a selection state changes, which feels quite expensive...
I wonder if we could just make the recycler view children a custom view that can handle reading the icon from a supplier (which owned by either the adapter or the coordinator)?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Naive question on the approach/ I don't have access to the design doc, so maybe some of the question already have answers
Added a direct link to the design doc in the bug comment #2 and now I think anyone with the link can view the doc.
Unit tests will be added as a chained CL since this CL is already large.
Done
for (int i = childrenCount - 1; i >= 0; --i) {Not a great fan of this traversal... it seems this section is meant to update the mouse icon during drag and drop.
Since Android event dispatcher usually starts from the child, back to the parent, I wonder if you can just override the child view's `onResolvePointerIcon` that you care about?
That is what I tried at first, but I think we directly need to modify CompositorViewHolder#onResolvePointerIcon. The reasoning is in this portion of the design doc (Section 8. in Proposed Design Changes):
There is also an on-going discussion with Theresa about why I added this specific traversal logic:
nit: Can you do [MotionEvent.obtain](https://developer.android.com/reference/android/view/MotionEvent#obtain(android.view.MotionEvent)) do copy the event?
Done
for (int i = 0; i < mRecyclerView.getChildCount(); i++) {
View child = mRecyclerView.getChildAt(i);
child.setPointerIcon(icon);
}This loops through the entire RecyclerView when a selection state changes, which feels quite expensive...
I wonder if we could just make the recycler view children a custom view that can handle reading the icon from a supplier (which owned by either the adapter or the coordinator)?
I think mRecyclerView.getChildCount() only returns the visible view count instead of the adapter count:
https://paste.googleplex.com/6260333788397568
And I think the loop is called only when the drag state changes (start drag, end drag, etc) so it does not run continuously during scroll or hover.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
for (int i = childrenCount - 1; i >= 0; --i) {Eleanor LeeNot a great fan of this traversal... it seems this section is meant to update the mouse icon during drag and drop.
Since Android event dispatcher usually starts from the child, back to the parent, I wonder if you can just override the child view's `onResolvePointerIcon` that you care about?
That is what I tried at first, but I think we directly need to modify CompositorViewHolder#onResolvePointerIcon. The reasoning is in this portion of the design doc (Section 8. in Proposed Design Changes):
There is also an on-going discussion with Theresa about why I added this specific traversal logic:
Thanks for the pointer. I see now why you want to replicate this logic (See my comment in https://docs.google.com/document/d/1NKsngqlhivcnXKt3sAoTmb43gimqb0VmySNDXa6ET9g/edit?resourcekey=0-lrr3M6yb-Rc3xcA_KGEFlg&disco=AAAByDAW4vs)
---
I do wonder though, if we can just check if the current mView is a native view, then just call the super method, to bypass these web content's pointer resolution logic?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
for (int i = childrenCount - 1; i >= 0; --i) {Eleanor LeeNot a great fan of this traversal... it seems this section is meant to update the mouse icon during drag and drop.
Since Android event dispatcher usually starts from the child, back to the parent, I wonder if you can just override the child view's `onResolvePointerIcon` that you care about?
That is what I tried at first, but I think we directly need to modify CompositorViewHolder#onResolvePointerIcon. The reasoning is in this portion of the design doc (Section 8. in Proposed Design Changes):
There is also an on-going discussion with Theresa about why I added this specific traversal logic:
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Glad this solution in patch#5 (forwarding event from CVH to mView) works :)
// Android has found the grabbing/grab cursor.nit: Remove this comment line - it's not necessary a grab cursor, it could be other views that has the cursor icon set ;)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
nit: Remove this comment line - it's not necessary a grab cursor, it could be other views that has the cursor icon set ;)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
5 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/android/java/src/org/chromium/chrome/browser/compositor/CompositorViewHolder.java
Insertions: 0, Deletions: 2.
@@ -386,8 +386,6 @@
// Delegate to standard Android behavior (View Group). This internally loops through the
// children of the CompositorViewHolder and calculates the correct offsets.
PointerIcon icon = super.onResolvePointerIcon(event, pointerIndex);
-
- // Android has found the grabbing/grab cursor.
if (icon != null) return icon;
}
```
[Drag and Drop] Add onTouchListener for drag handle
The link for the design doc is in the bug in comment #2.
This CL covers sections 6. and 8. under "Proposed Design Changes".
After: https://screencast.googleplex.com/cast/NDc2NDcwMjEyMTkxODQ2NHwzNTFhZWRiOS1iNw
Notice that the mouse behavior is currently imperfect since we have not implemented hover listeners for the row body and the grab handle (will be chained to this CL).
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |