Repository: themesberg/flowbite-react

Issue #1083: Modals buggy on mobile
Created: 2023-10-22T18:43:26Z
I have searched the Issues to see if this bug has already been reported
 I have tested the latest version

Steps to reproduce
I have found multiple issues with the default flowbite-react modals when viewed on mobile. I initially found these issues in my own app and then later discovered they are also broken on the official flowbite-react docs website.

Go to: https://www.flowbite-react.com/docs/components/modal on any browser in mobile
Click on any of the Toggle Modal buttons

Current behavior


a. The modal appears so high up that the close "X" button is not visible, making some of the modals in the examples screen unclosable
b. The modals do not appear centred by default (I could understand this is a stylistic decision, but it's a bit strange to have pop-ups appear at the top of the screen)
c. If you go into developer tools and add lots of extra text to one of the modals, you will see it will expand so far below down to the screen that the padding & rounded corners of the modal dissappear on the bottom. This only happens on chrome & safari.

Expected behavior

I would expect Modals to be fully visible and centred by default, and not require theme overwrites to accomplish this.
I would expect the padding around the modal to always be visible even as the content of the modal grows.

Context
Environments:

Tested on iOS devices using chrome, firefox & safari
Tested in an android emulator using only chrome
Issue not present on desktop, and also not on desktop when using the "Responsive Design Mode", only happens on-device

Fix suggestions:

Problem a and b can be quite simply solved by using flex and centring the modal with justify-content
Problem c is caused here: 
  
    
      flowbite-react/src/components/Modal/theme.ts
    
    
         Line 36
      in
      4f0399b
    
  
  
    

        
          
           inner: 'relative rounded-lg bg-white shadow dark:bg-gray-700 flex flex-col max-h-[90vh]', 
        
    
  



Using max-h-[90vh] is pretty bad as vh is treated differently by different browsers on mobile. For example safari and chrome will think of the "view height" as extending under & below the browser's own footer UI element, while Firefox thinks of "view height" as until its own footer UI element.
It would be better to remove the vh usage here and allow the modal to just expand to max-height 100% then it will always stay within the padding of its parent element.
vh is also being used here and should also be fixed to use height: 100% instead: 
  
    
      flowbite-react/src/components/Modal/theme.ts
    
    
         Line 5
      in
      4f0399b
    
  
  
    

        
          
           base: 'fixed top-0 right-0 left-0 z-50 h-modal h-screen overflow-y-auto overflow-x-hidden md:inset-0 md:h-full', 
        
    
  





I was able to solve these problems in my app with the following theme override:
theme={{
  root: {
    // Replace: h-modal h-screen with h-full
    base: 'fixed top-0 right-0 left-0 z-50 h-full overflow-y-auto overflow-x-hidden md:inset-0 md:h-full',
  },
  content: {
    // Added: flex flex-col justify-center
    base: 'relative h-full w-full p-4 md:h-auto flex flex-col justify-center',
    // Added: max-h-full max-w-full overflow-hidden
    inner: 'relative rounded-lg bg-white shadow dark:bg-gray-700 flex flex-col',
  },
}}

Hope this helps!

Duplicate issue #1169: Modal incorrect vertical position on screens below md. 
Created: 2023-12-03T21:06:47Z
I have searched the Issues to see if this bug has already been reported
 I have tested the latest version

Steps to reproduce

Import and use the modal component in React.js
Set position prop to "center"
Reduce window width and observe that the modal always appears at the top of the screen.

Current behavior
The position="center" prop doesn't center the modal vertically on smaller screens of sizes below md.
Expected behavior
Expected the modal to be centered vertically too.
Context

Closing comment (2024-01-01T19:54:50Z): This is technically a duplicate of #1083 though