Ensure the CoL can scroll to the bottommost elements of the scrolling child, which may not be visible due to the app bar.
Also, set the node info properties to expose the CoL to auto-scrolling.
PiperOrigin-RevId: 447596411
(cherry picked from commit 72228f4f35b0c155c870f59bc7c807e05443bf95)
When a snack bar is hidden and its show() method is called, it will be added to the target parent, and at this moment the parent view will set the layout params to the snack bar, with the same existing margins if any. Therefore if the margins are already updated with extra margins, the original margins will be incorrectly updated. This CL introduces a flag to tells this situation from other "real" scenarios in which clients want to update their custom margins.
Resolves https://github.com/material-components/material-components-android/issues/2666
PiperOrigin-RevId: 445159923
(cherry picked from commit 46fa8cc45b8bb6d1423f7349986c7f3f4cdc5d4e)
When an AppBarLayout is loaded, it will load the attribute and set up a non-forcing pending action. However when it's measured, the current scroll state will be saved and restored, which will override the non-forcing pending action. This behavior is incorrect - if there's a pending action, we shouldn't restore the scrolling state because it's meant to be changed.
Resolves https://github.com/material-components/material-components-android/issues/2629
PiperOrigin-RevId: 440960254
(cherry picked from commit 05be1b92c5720e4c6c6f42f93918bd6554099625)
When the date picker goes back from background to foreground, the onStart() method will be called and make enableEdgeToEdge() be called again. This will make it incorrectly use the header height and top padding already adjusted with system inset as the original height and padding, and thus add the inset multiple times.
Creates a flag to only enable edge-to-edge once to fix the issue.
Resolves https://github.com/material-components/material-components-android/issues/2628
PiperOrigin-RevId: 440110562
(cherry picked from commit c6a654c7dd68827a55d6d3dcda424cf6749678fa)
Before, in requestRectangleOnScreen we were setting the text input layout’s rectangle to a specific and constant position, which caused the zoomed in screen to be fixed to the left instead of following the input text as it was typed. We should use the edit text’s rectangle’s position first, then adjust for the text field’s height (which includes the helper/error text), then use that updated rectangle on the super call of the method.
PiperOrigin-RevId: 435402032
(cherry picked from commit dce4419744ba4e336e31a80521ab8a9ecb1136de)
Removed the Context/Application/Activity in the Builders class.
Updated docs accordingly and added examples explaining how harmonizing color attributes with theme overlay works.
PiperOrigin-RevId: 433769484
Reduces and restructures the calling chain when a state is set to improve readability and robustness.
This CL also introduces the following fixes:
1. Limit the possible input values of setState() and throws IllegalArgumentException if invalid values are provided.
2. Block the state to be set as HIDDEN when hideable is false.
3. Fix the bug that SettleRunnable could be posted multiple times due to isPosted flag being incorrectly set to false when the settling is still going on.
4. Fix the bug that dragging the bottom sheet when settling would result the bottom sheet in an incorrect state (the target state of settling instead of DRAGGING).
PiperOrigin-RevId: 432963533
We already had class documentation that explains that TextInputEditText should be instantiated with the parent TextInputLayout's context for proper theming, but this information is important enough to the basic usage of TextInputLayout and TextInputEditText that it's best to have it the class documentation, as well.
Added the guidance in both TextInputLayout and TextInputEditText because it's relevant to both classes.
PiperOrigin-RevId: 432244388
The activity leak can happen in a corner case: setting bottom sheet state when the bottom sheet is dismissed and the host activity is closed. In this situation SettleRunnable will be posted to ViewRootImpl since the bottom sheet is not attached, which leaves references of the dismissed bottom sheet (and thus the destroyed activity) in ViewRootImpl and causes activity leak.
Fixes this by using weak reference in SettleRunnable instead of the strong reference, which is the standard practice of the BottomSheetBehavior class.
Resolves https://github.com/material-components/material-components-android/issues/1417
PiperOrigin-RevId: 430709002
