Skip to content

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

Closed
@joemaffei

Description

@joemaffei
Contributor

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.?.?

Activity

added
component: dialogThis is the name of the generic UI component, not the React module!
component: drawerThis is the name of the generic UI component, not the React module!
and removed
component: dialogThis is the name of the generic UI component, not the React module!
on Jul 26, 2018
oliviertassinari

oliviertassinari commented on Jul 26, 2018

@oliviertassinari
Member

@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? :)

added
good first issueGreat for first contributions. Enable to learn the contribution process.
new featureNew feature or request
on Jul 26, 2018
joemaffei

joemaffei commented on Jul 26, 2018

@joemaffei
ContributorAuthor

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

joemaffei

joemaffei commented on Aug 15, 2018

@joemaffei
ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component: drawerThis is the name of the generic UI component, not the React module!good first issueGreat for first contributions. Enable to learn the contribution process.new featureNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @oliviertassinari@joemaffei

        Issue actions

          Mobile Safari: elements set to 100vh can be hidden behind the button bar · Issue #12285 · mui/material-ui