Is this a mobile Safari bug? White space appears at bottom after rotating iPhone

[smirk]

Hi, I'm encountering a really strange issue that I've tracked down to only occurring in iOS Safari starting with iOS 12.2.

The issue is this. When you first bring up a web page that specifies a height of 100% on the iPhone, it looks fine. Rotate it to landscape and it also looks fine. When you rotate it back to portrait, the bottom of the usable content shrinks up the page a little, leaving a white space at the bottom. There doesn't seem to be any way to place content there, it's as if Safari thinks the physical window is shorter than it is. The height of the white space also seems to add up to the height of the URL and navigation bars, if they were showing.

I put an example here: https://noderun.com/run/jeff/possible-ios-safari-bug/
Code is here: https://noderun.com/ide/jeff/possible-ios-safari-bug/

(NodeRun.com is like CodePen)

Is this a known issue? It seems like if it were a Safari bug that this would happen all over the place.

Here's the page before and after rotating:



Thanks!

 

[olup]

I've had issues with IOS Safari with stuff like this, so it's probably a bug. You could try to account for the 45 - 50px gap, roughly the height of the bottom bar of safari, on the bottom by adding a scroll event listener once it gets to that threshold and remove/add the height of that gap.

 

[smirk]

I've had issues with IOS Safari with stuff like this, so it's probably a bug. You could try to account for the 45 - 50px gap, roughly the height of the bottom bar of safari, on the bottom by adding a scroll event listener once it gets to that threshold and remove/add the height of that gap.

How would you do that? In my tests, offsetHeight is being returned with the wrong (artificially short) value. Is there another way to get the actual height?

Thanks!

 

[olup]

you mean the actual height of the bottom bar? I've always taken screenshots of Safari and measured the height of the bottom bar on window load. Have a look at the Intersection Observer API. There's something called root margin, which is the margin around the root element that you're checking against.

 

[lololissimo]

I’ve stumbled upon exactly the same problem. What I don’t understand is how come this is the only report I could find. Any height:100% div in a height:100% body would do that! Did you manage to overcome it, @smirk?

 

[olup]

I’ve stumbled upon exactly the same problem. What I don’t understand is how come this is the only report I could find. Any height:100% div in a height:100% body would do that! Did you manage to overcome it, @smirk?

Take a look at my post above yours, where I've linked to the intersection observer on MDN. I don't think there's a plain CSS solution to this. What would need to happen is that you set the observer to an onscroll event, where the 50px from the navigation bar is subtracted once the page is loaded and re-added once the scrolling starts. I hope this will help.

let options = {
    // the parent element, in this case the body, which should get an ID of body or similar
    root: document.getElementById("body"),
    // the bottom margin equivalent to the height of the navigation bar at the bottom of IOS safari
    rootMargin: "0 0 50px 0",
    threshold: 1
}

// initialize intersection observer
let observer = new IntersectionObserver(callback, options);

 

[ethanmarcos]

I would recommend you use an alternate browser. I am not a fan of safari

 

[smirk]

I’ve stumbled upon exactly the same problem. What I don’t understand is how come this is the only report I could find. Any height:100% div in a height:100% body would do that! Did you manage to overcome it, @smirk?

Hi, I stopped working on this issue for awhile but now I'm back looking at it. It is affecting all of our mobile apps. I also don't understand why reports of this aren't more widespread. I'll keep you updated if I discover a work around.

I would recommend you use an alternate browser. I am not a fan of safari

That's not particularly helpful, although I thought the same thing. But we can't tell our customers to install and use a different web browser just for our app.
[automerge]1581096778[/automerge]

Take a look at my post above yours, where I've linked to the intersection observer on MDN. I don't think there's a plain CSS solution to this. What would need to happen is that you set the observer to an onscroll event, where the 50px from the navigation bar is subtracted once the page is loaded and re-added once the scrolling starts. I hope this will help.

Thanks for your reply, but I'm not following you. What does scrolling have to do with it? What's happening is you bring up a page in portrait, then rotate the phone to landscape, then rotate back to portrait -- with or without scrolling along the way -- and then the layout gets all messed up. There is a section at the bottom of the screen that seems unusable and unreachable. Sometimes the height of this section seems to equal the height of the hidden browser control elements, but sometimes the height seems much larger than that. I don't have all my facts straight yet, but it's possible that iPhone X-class devices have taller unusable sections than iPhone 8-class ones.

So maybe you're onto something, but I'm not getting how scrolling fits into this.

 

[olup]

Hi, I stopped working on this issue for awhile but now I'm back looking at it. It is affecting all of our mobile apps. I also don't understand why reports of this aren't more widespread. I'll keep you updated if I discover a work around.


That's not particularly helpful, although I thought the same thing. But we can't tell our customers to install and use a different web browser just for our app.
[automerge]1581096778[/automerge]


Thanks for your reply, but I'm not following you. What does scrolling have to do with it? What's happening is you bring up a page in portrait, then rotate the phone to landscape, then rotate back to portrait -- with or without scrolling along the way -- and then the layout gets all messed up. There is a section at the bottom of the screen that seems unusable and unreachable. Sometimes the height of this section seems to equal the height of the hidden browser control elements, but sometimes the height seems much larger than that. I don't have all my facts straight yet, but it's possible that iPhone X-class devices have taller unusable sections than iPhone 8-class ones.

So maybe you're onto something, but I'm not getting how scrolling fits into this.

Sorry for confussion, I've actually only used that for scrolling events, but the concept would remain the same, but for an onload event instead. The orientation media query might also work though.

@media (orientation: portrait) {
    body {
        height: 100%;
    }
}

@media (orientation: landscape) {
    body {
        height: calc(100% - 50px);
    }
}

 

[smirk]

So I did some experimenting, and setting body to height: 100vh; seems to be working so far. All its children are using a height of 100%, and so far so good. I'll keep playing with it.

 

[olup]

?

 

[smirk]

Hey, I take it back -- it's not working with body set to height:100vh;. Doing that seemed to help when I used browser tools to change those properties when my phone had our app up, but I distilled it down to a very simple HTML page that exhibits the issue, and using 100vh doesn't affect it.

Viewing this page in iOS 13 shows the white space at the bottom after rotating to landscape and back.

<!DOCTYPE html>
<html>
<head>
<title>Test Page!</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
  <div style="position:absolute; padding:0px; margin:0px; border-width:0px; height:100%; width:100%; background-color:blue;">Rotate me</div>
</body>
</html>

 

[coder7of9]

I am still working on finding an elegant solution.
This approach re-instates the correct height on iphone.

    html{height:100%;}

    body{margin: 0;min-height:100%;height:100%;overflow:hidden;}



    window.addEventListener('resize', function() {

        if ( window.matchMedia("(orientation: portrait)").matches ) {

            document.getElementsByTagName("html")[0].style.height = "100vh";

            setTimeout(function(){

                document.getElementsByTagName("html")[0].style.height = "100%";

            }, 500);

        }

    });

 

[mala3103]

Hello guys So I had the same problem, and I used a solution that @coder7of9 proposed. For me this is working on the iPhone, so thank you very much. Also to mention, that code can cause side effects on the iPad, so maybe to find a way to exclude it, with some method for example.

 

[PLawless]

Hello! I joined MacRumors just so I could participate in this thread.

I'm running the example through an Xcode simulator but cannot reproduce the defect. Is that just me or has something changed there?

However, I am having the exact same issue in my app. I noticed that if I dismiss the toolbar after rotating back to portrait orientation, everything snaps to fill all the available space and the defect does not happen again with subsequent transitions between landscape and portrait. Can anyone think of why that may be?

 

[mala3103]

Hello @PLawless , I also joined because of this thread

I think that nothing changed, I recently posted, so I don't think that Safari fixed the issue if you think on that. Please try on a real device, not a simulator, because I also didn't reproduce on a simulator. Somehow look like CSS of Safari is broken, that's my thought and doesn't recalculate nice height, also there is some collision if you have buttons in that area. Did you try workaround that's above?

 

[PLawless]

Hey @mala3103, I did try the workaround but the timeout interval caused the screen to shift, which won't be acceptable in my situation. Perhaps a CSS animation might work? I'll give that a try.

Strange that the provided example won't present on the simulator.

If this is a bug with Safari, should we be reaching out to Apple to fix it?

 

[PLawless]

FYI I cannot reproduce the defect on a real device either (in my case: iPhone XR, iOS13.3)

 

[mala3103]

I reproduced it on iOS 13.2.2 - iPhone 8. I think that version of iOS is not important, instead of that device resolution. When searched this was the only thing that I found out and fits for me. Other suggestions also were with style but to set the body to 100vh, or scrollable and similar.

My first idea was to trigger a scroll event every time when orientation is changed, and it's a portrait, but that didn't work in my case. Let us know if you have any new findings.

 

[olup]

I came across this tweet today that fixes the min-height: 100vh bug on mobile safari. Not sure, if it addresses the address bar issue though.

body {
  min-height: 100vh;
  /* mobile viewport bug fix */
  min-height: -webkit-fill-available;
}

 

[hunainhashim]

Hi everyone, I am having the same issue when I apply the css property "position fixed" on body after hiding the address bar by scrolling the page. I tried all the solutions mentioned above but none of them are working for me. If you guys found the solution please share it here.

Thanks