Drawer component behaves unexpectdly with Forms, Input Field Loses Focus and Draggable Class Added on Click.

[itse4elhaam]

I have a form inside the drawer, text area and selects both work fine but input tags don't get focused when clicked by a mouse, it works when using tab though.

I think the drawer doesn't differentiate correctly between dragging click and input focus click.

To Reproduce, create a drawer component with a form inside it which contains input fields, I used Shadcn Input, Labels, Selects and everything.

Loved the new components but this issue is really bothering me.

[itse4elhaam]

Not sure but it might be related to these, haven't found any fixes yet.

• [Modal] Cannot focus iframe when open mui/material-ui#17497
• Event API: Add FocusScope surface facebook/react#15487
• [TrapFocus] Steals focus from nested portal mui/material-ui#15694

[itse4elhaam]

Also this is happening on chrome/chromium browsers - namely edge/chrome.

[demczenko]

Also have the same issue with inputs.

[ap-1]

I'm having the opposite issue---I can focus on inputs but dragging seems to be broken (Firefox Developer Edition)

[abeisleem]

Also having same issue. Specifically with shadcn Form element. Not an issue when using regular <form> with shadcn <Input> element (as shown in the Responsive Dialog example).

[GuillemotF]

I found an alternative to keep the focus on the input when clicking, in return the drawer can no longer be moved when dragging from the input area.

Add this to your input component :

<input
      onPointerDown={(e) => e.stopPropagation()}
      ...
/>

[Baptistews]

This issue is still ongoing

Adding stopPropagation onpointerdown to the input fix it completely tho

[alizada-hadi]

I also have this issue with input, and textarea.

[itse4elhaam]

I found an alternative to keep the focus on the input when clicking, in return the drawer can no longer be moved when dragging from the input area.

Add this to your input component :

<input
      onPointerDown={(e) => e.stopPropagation()}
      ...
/>

@shadcn You should consider adding this solution (or a better one) to this component.

[AdiRishi]

Just ran into this myself. I tried the onPointerDown solution proposed but it didn't do much. DId anyone figure out a solution?

[ramyjaber1]

i have exactly the same problem does anyone find a proper solution other than onPointerDown because it didn't work for me

[CarlosSousa2001]

Esta opção funcionou, eu estava com um dentro do Drawer e o calendário do input não abria

<input type={'date'} onPointerDown={(e) => e.stopPropagation()} ... />

[bertinselendo]

@itse4elhaam @AdiRishi @ramyjaber1 @shadcn

Here's how to simply fix this problem without sacrificing anything

modify the drawer component in src/components/ui/drawer.tsx and do this

[shadcn]

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

[mohamed-younes16]

i still have same issue

[sujjeee]

hey @AdiRishi got any way to fix your issue?

[AdiRishi]

@sujjeee no unfortunately I didn't 😞 . I ended up switching to the Sheet component. Very similar visual style and it doesn't suffer the same issues on mobile.

[etozhealkhipce]

I was able to fix this by adding to disablePreventScroll props to drawer component

<Drawer
      open={isOpen}
      onClose={onClose}
      disablePreventScroll
    > 
     ...
</Drawer>

[adnan-razzaq]

we are still facing this issue with recent versions

[amirrstm]

Fixed when adding repositionInputs as false in Drawer root.
<DrawerPrimitive.Root repositionInputs={false} {...props} />

[verxm]

I had the same problem, but my Inputs were inside a Form that was inside a Dialog that was called by a Drawer.

I managed to solve the Dialog problem by following the recommendations in the comments:

• Dialog Overflow Behavior #16 (comment)
• https://stackoverflow.com/questions/69495070/prevent-zooming-in-after-input-field-focus-in-firefox-on-mobile

After these changes, the use of inputs in the Dialog opened directly will work fine, but it still had the same behavior when opening the Dialog in a Drawer.

In my research, I didn't find any suggestion that worked for my case. But when I studied the Drawer properties a little more deeply, I saw a property called repositionInputs, and setting its value to false worked perfectly.

Correction:

...
<Drawer repositionInputs={false}>
...
<Drawer/>

Hope this helps.