Dan Nizri

Also, in some cases I believe the doubly nested scrolling works without flickering via the standard CoordinatorLayout APIs (and no liftOnScrollTargetViewId), so this PR could be disabling the current lift...

The ScrollingViewBehavior itself should definitely be set on the sibling, but technically CoordinatorLayout supports sending up nested scrolling events up the hierarchy via the behavior's APIs.

I'm trying to understand whether this will cause a regression for some cases where `appbar_scrolling_view_behavior` is set and there is a nested scrolling view (e.g. FrameLayout with `appbar_scrolling_view_behavior` and `NestedScrollView`...

> After applying the PR, AppBarLayout will never be lifted, because the direct child with appbar_scrolling_view_behavior (FrameLayout) cannot be scrolled vertically (as intended). A FrameLayout with appbar_scrolling_view_behavior and a scrolling...

I just linked that one post as an example of the pre-existing behavior which is somewhat like a contract at this point. I am aware of many internal and external...

I don't really remember, maybe updateMargins() was originally not called as often as it is now? @pubiqq do you know why the post() is not necessary anymore and you can...

@paulfthomas can you take a look at the implementation issues and raise the spec issues with design?

NavigationView is like the menu item content that can be placed within either a side nav drawer or a bottom sheet, or it can be used independently and placed anywhere...

@MohamedElattar22 can you provide some more details? (explanation, code snippets, screenshots)

@kelalaka153 can you try using `app:simpleItemLayout` on the `MaterialAutoCompleteTextView` to pass in your custom layout instead of making your own adapter?