Implementing material compose’s `ModalDrawer` , I noticed, with the drawer closed, the entire screen...

# compose-android

[Mark]

Implementing material compose’s ModalDrawer , I noticed, with the drawer closed, the entire screen is used to detect a horizontal drag gesture to open the drawer. This is very different from androidx.drawerlayout.widget.DrawerLayout which only detects long-tap on the edge of the screen (and then pokes out a small part of the drawer to indicate drag can proceed).

The problem with ModalDrawer is that it’s way too easy to accidentally trigger opening the drawer when doing normal vertical scrolling in the main app.

I tried disabling gestures but then you don’t get the long-tap edge detection described above.

Perhaps there is a way to achieve the old behavior using anchoredDraggable modifier?

[Colton Idle]

lmao. im facing this same issue. we have a screen where a user can basically tap from left to right for some content input. but it triggers the modal drawer on some device with slow screens/digitizers.

we disabled gestures, but now it sucks that you can't slide the navigation drawer back in once you click the hamburger menu to come out. id love to see an option here like Mark is describing.

[Mark]

Hasn’t ModalDrawer been around for a few years? Hard to believe no one else experiencing this.

[Colton Idle]

A few years is pushing it (I think) lol. Still feels like compose came out yesterday.

[Mark]

Three years 🙂 https://cs.android.com/androidx/platform/frameworks/support/+/c1c2fe780bdf75379b909ad2a829927016bfd7ba

[Colton Idle]

😱

[Mark]

I guess you are not using Scaffold? Me neither. Have you tried using Scaffold and ModalDrawerSheet instead?

[Colton Idle]

Nope. No scaffold. I honestly don't know which one to use. So maybe that's the issue?

[Mark]

The reason I’m not using Scaffold is because I’m still using a legacy (View) AppBarLayout. I managed to hook it up to the ModalDrawer which kind of works although the hamburger icon is not animating. Also the content (screen content) is an AndroidView , though that also seems to be working.

[Colton Idle]

Oooh. Maybe that's what I should switch to. I'll try tomorrow when I'm at my desk

[Mark]

Scaffold didn’t make any difference (at least not for M2). However this is interesting: https://stackoverflow.com/a/69457960

drawerGesturesEnabled = scaffoldState.drawerState.isOpen // Scaffold
gesturesEnabled = drawerState.isOpen // ModalDrawer

[Mark]

Oh, are you also using an AndroidView in your screen content? See:

<https://issuetracker.google.com/issues/202569585#comment4>

[Colton Idle]

I am not, no

[Mark]

I added an issue. Let’s see. https://issuetracker.google.com/issues/323400867

[Colton Idle]

hit this issue again today actually on another project. lol. any thoughts on this @Louis Pullen-Freilich [G] or maybe routing the request to the right place?

[Louis Pullen-Freilich [G]]

We'll re-reroute: in general though the platform behaviour is just inherited and not explicitly specced by Material, so there isn't really a 'correct' behaviour here, we will need to figure out at the component level what the correct behaviour would be. Given that this behaviour has existed for a few years in Compose though, to be transparent it's a low priority issue given that it involves a behaviour change, and that few people have noticed the change in behaviour

[Colton Idle]

Gotcha. so i wont hold my breath. i suppose it shouldn't be too bad to fork this.

any tips you can give on when to use the modal nav drawer vs the others?

[Louis Pullen-Freilich [G]]

You mean nav drawer vs sheet?

[Colton Idle]

seems like there modal nav drawer, nav sheet, plain ol navigation drawer.

[Colton Idle]

hm. maybe i misinterpreted what @Mark said above. I thought there was a modal version and a version where you have to use it in a scaffold. But I think I just want a "regular" navigation drawer that most of us are used to. i think thats a modal nav drawer.

[Louis Pullen-Freilich [G]]

There’s some guidance on material.io, e.g: https://m3.material.io/components/navigation-drawer/overview

In general it depends on window size, and also importance of the content / how it relates to the screen

[Colton Idle]

gothca. i think this is what i needed to read. "[Modal drawers] can be swapped with standard drawers on expanded, large and extra-large window sizes."

So i do indeed want a modal on my compact /medium devices.

@Mark ill try to hack something together where i can disable the full screen being used to drag and isntead just use a little bit of the screen. maybe i can look into m2 compose nav drawer. lol

[Mark]

I’m very surprised that no one seems to have mentioned this issue before. I can only guess that they just disabled gestures as a way to deal with the it. My current workaround is to disable gestures and enable long-tap on top-left up icon to provide a way to access the drawer from non-home screen. The legacy way of long-tapping on the left edge was never great anyway.

BTW, I don’t think there needs to a be a behaviour change (to default behaviour). Couldn’t it be some configuration arg instead?

[Colton Idle]

Yeah. In my case. I don't want gestures to pull the drawer out. but i want the gesture to slide it away OR at the very list to tap on the scrim so that it hides. but both of those are disabled when gestures are disabled.

[Colton Idle]

ill probably just fork.

[Mark]

In that case you can just do

drawerGesturesEnabled = scaffoldState.drawerState.isOpen // Scaffold
gesturesEnabled = drawerState.isOpen // ModalDrawer

[Colton Idle]

oh snap. was it that easy after all?

[Colton Idle]

ill try that tomorrow though. lol

[Mark]

It definitely helps (and solves your issue), but doesn’t quite solve mine.

[Colton Idle]

That worked. Thanks Mark!

[Colton Idle]

bah. i have a webview based app, and need a nav drawer with pull to slide, but it is WAY too over eager. basically makes the webview unusable. gotta start looking into this again now. 😂