This change is a slight alteration to the change introduced in cl/347036858 this moves the added code to the bottom of the method so as to not interfere with the recursive call.
BEGIN_PUBLIC
Made a slight change to move adding `presentingViewYOffset' to `_contentHeightSurplus` to the end of the method. This was added in a previous change but didn't take into account the possibility of an infinite recursive loop. This movement should prevent that while also updating `_contentHeightSurplus` to the proper value. This should also fix the bug brought up in b/176122058
END_PUBLIC
PiperOrigin-RevId: 351455638
BEGIN_PUBLIC
Updated the `contentHeightSurplus` method to add in an additional value of `presentingViewYOffset'. In the current iteration the `presentingViewYOffset' gets cancelled out by being included in both `scrollingDistance` and `containerHeight`. This change will take that offset back in to account and resolves a UX bug that we're currently seeing devices with smaller screen sizes using the PageSheet presentation style (b/173830907).
END_PUBLIC
PiperOrigin-RevId: 347036858
BEGIN_PUBLIC
Updated the `presentingViewYOffset` conditional in `MDCBottomDrawerContainerViewController`. Checking the `verticalSizeClass` trait doesn't seem to provide value for the conditional seeing as regardless of screen size we would still need a y offset and would default to zero if the value wasn't large enough anyways. Taking off this conditional would also make it easier to create unit tests for a future related CL that will take the `presentingViewYOffset` into account. I tested this change by running the drive app and the material catalog app to search for an UX discrepancies. I also ran the unit and snapshot tests associated with this class and they passed fine with just a small change in the golden image needed
END_PUBLIC
PiperOrigin-RevId: 345987236
Cause:
The variable dismissOnBackgroundTap should be used to determine whether gesture recognizer is added to the presentation view controller. When the check was removed, gesture recognizer is interfering and touchesended is not propagated.
Fix:
Add back the check and add tap gesture recognizer only when dismissOnBackgroundTap is set to true.
PiperOrigin-RevId: 336292017
This adds a dismissOnAccessibilityPerformEscape bit that allows clients to control whether the bottom drawer should dismiss or not on Z swipe. This is useful for when clients have an extra step before dismissal (e.g. confirmation on dismiss).
PiperOrigin-RevId: 331594189
This adds a new property to MDCBottomDrawerViewController and MDCBottomDrawerContainerViewController that allows for non-fullscreen mobile landscape bottom drawer view.
PiperOrigin-RevId: 327626953
This adds a new property to MDCBottomDrawerViewController that allows for non-fullscreen mobile landscape bottom drawer view.
PiperOrigin-RevId: 327070504
(One of the previous MDCBottom* CLs was reverted b/c the layout changes caused a bug in OneGoogle's bottom drawer spec. This CL has a property described below that allows apps to adopt the change on their own schedule.)
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
1) Update the MDCBottom* classes with properties and layout adjustments to have the container view controller use the window's size instead of the screen's size in iPad Slide Over.
2) Default this new property to NO to maintain old behavior for all other apps that use MDCBottom* to avoid forced adoption and potential bugs.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it's within a taller window.
Before and after screenshots in b/159595242.
PiperOrigin-RevId: 320475781
BEGIN_PUBLIC
Revert MDC Bottom Drawer behavior change for iPad Slide Over.
The change introduced issues in downstream components.
END_PUBLIC
*** Reason for rollback ***
The original CL changes OneGoogle's bottom drawer behavior against the spec.
See b/160351551
*** Original change description ***
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it'...
***
PiperOrigin-RevId: 319809092
BEGIN_PUBLIC
Fix bug where MDCBottomDrawerContainerViewController has the size of the screen instead of the window when in iPad Slide Over.
END_PUBLIC
MDCBottomDrawerContainerViewController has the wrong size in iPad Slide Over (when the window height is shorter than the screen height), causing GTETaskCreationViewController to have the wrong y origin b/c it thinks it's within a taller window.
Note: this is 1 of 2 parts to the fix for b/only fixes. The after screenshots below are only partially correct and will be fixed in the next CL.
Before and after screenshots in b/159595242.
PiperOrigin-RevId: 319253730
This change adds a new theming method, `-[MDCBottomDrawerViewController+MaterialTheming applyThemeWithScheme:applyToTrackingScrollView:]` to allow clients to opt-in to functionality which sets `-[MDCBottomDrawerViewController trackingScrollView].backgroundColor` to the theme's background color.
PiperOrigin-RevId: 317116346
In 33daf325e6 (diff-a3db687b7d16849448cb7f189976eb0f) we added this property to allow the drawer to support max height. In adding this property my assumption was that we needed to shift the scroll view down by the amount of the topSafeArea but this is an incorrect assumption, we should leave it to the client to determine the height of the drawer an not _magically_ shift it down by an amount. Also, we tied the drawer max height to the `shouldIncludeSafeAreaInContentHeight` to the height of the drawer this caused the drawer to be shifted down by the safeArea.bottom height. The property `shouldIncludeSafeAreaInContentHeight` is related to the `maximumInitialDrawerHeight` property but not the `maximumDrawerHeight` property. Both of these values should be on the client to pass in instead of us _magically_ shifting down potentially causing issues where a client expects the drawer to be "x" height but it shows as "x - (safeArea.top + safeArea.bottom)".
Tested via the catalog examples.
PiperOrigin-RevId: 314127239
We recommend clients set the tracking scroll view of the navigation drawer so that they have a smooth scrolling experience but before this change it could be confusing if we intended clients to set this property to a scroll view from their content view controller or if it was an internal one.
PiperOrigin-RevId: 314124930
If a client sets the `maximumDrawerHeight` and the `maximumInitialDrawerHeight` to the same value then the drawer should be opened to its _max_ height. Currently if that happens the drawer allows for _safeArea.top_ pts of scrolling. This is due to us adjusting the `contentHeaderTopInset` which is then used to layout all the content. We typically adjust it because we assume that the header adds the _safeArea.top_ pts to it's height as it approaches the safe area. So really the `contentHeaderTopInset` typically _maxes out_ at that amount but if we never approach the safe area then we need to allow for this value to be 0.
Tested in the Catalog via Infinite Scrolling example.
PiperOrigin-RevId: 313814020
