Mobile Safari: elements set to 100vh can be hidden behind the button bar

[joemaffei]

I recently ran into an issue where a button anchored to the bottom of a Drawer was hidden behind mobile Safari's button bar. Looking for solutions to this problem, I found this comment, which linked to this article. The article describes how Safari and other mobile browsers have a unique interpretation of what 100vh means, which includes the area behind the button bar at the bottom.

Luckily, the workaround is easy: the browser interprets a height of 100% to be the full height of the visible space at any given moment, whereas 100vw is the full height of the viewport after a scroll event causes the button bar to disappear. It's counterintuitive, but it means that the more common value of 100% works for all platforms.

Material-ui has the Drawer component set to a default height of 100vh. This not only causes a problem in mobile browsers, but it could be argued that 100% is a more logical value. For example, a Drawer used to house navigation elements should be the same height as its container, not as the viewport. Think of a modal with fixed navigation on the left and you'll understand where I'm coming from.

My experience was in regards to the Drawer, but I believe any other components set to a height of 100vh run the risk of being covered by mobile browser navigation buttons.

• This is a v1.x issue.
• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Elements at the bottom of a full-height component like Drawer should be visible on all browsers.

Current Behavior

Some mobile browsers (like Safari on iOS) hide the bottommost elements in a full-height component behind button bars at the bottom.

Steps to Reproduce

Take a look at this simple example: https://codesandbox.io/s/1qy5mrwjw3
To see the sandbox in your browser, open this URL: https://1qy5mrwjw3.codesandbox.io/
On mobile Safari, the button bar covers the red rectangle.

Create a fork of this sandbox and take note of the new url in the "browser" pane on the right. Uncomment height: '100%' and save. Open that url in mobile Safari. You should be able to see the red rectangle.

Tech	Version
Material-UI	v1.1.0
React	16.1.1
browser	Mobile Safari
device	confirmed on iPhone 6, 8 and X
iOS	11.4.1 and 10.?.?

[oliviertassinari]

@joemaffei This issue remembers me #11349 for a different component. I think that each component use cases are different and tradeoffs need to be made on their context. Safari feedback is very interesting:

This is completely intentional. It took quite a bit of work on our part to achieve this effect.:)

The base problem is this: the visible area changes dynamically as you scroll. If we update the CSS viewport height accordingly, we need to update the layout during the scroll. Not only that looks like shit, but doing that at 60 FPS is practically impossible in most pages (60 FPS is the baseline framerate on iOS).

It is hard to show you the “looks like shit” part, but imagine as you scroll, the contents moves and what you want on screen is continuously shifting.

Dynamically updating the height was not working, we had a few choices: drop viewport units on iOS, match the document size like before iOS 8, use the small view size, use the large view size.

From the data we had, using the larger view size was the best compromise. Most website using viewport units were looking great most of the time.

https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html#february-23rd-update

We need to make sure we don't harm the scroll experience. For the variant="temporary" I'm 💯 with you. We need to change the approach! For the other variants, well the choice is harder to make. I don't see the use case of a non variant temporary on an iPhone, so it doesn't matter. For the iPad, well, 100vh provides a better UX but it's affecting a small part of the screen, so I think that for the sake of simplicity we can go with 100%.

Do you want to work on it? :)

[joemaffei]

@oliviertassinari Yes, I'd love to contribute to the project!

[joemaffei]

I just opened a pull request for this issue: #12528