Fullpage.js: Mobile Safari height wrong with address bar and tabs

[MickL]

The height of a section is not set correctly on iOS Safari. You may try this out in Xcode Simulator. For example on iPhone 7 Plus the height of the viewport (without toolbar) is 370px, but the fullpage.js height of a section(set by $(window).height()) is 414px which includes the toolbar(address bar).

To show this i added a header and a footer which are positioned absolute (top:0 / bottom:0).

Initial:

Using $(window).scrollTop(1000):

A solution would be to use window.innerHeight. Interestingly it gives 414px (height with toolbar) on start, but with a timeout of 50ms it gives 370px (correct height without toolbar):

1. Replace all $(window).height() with window.innerHeight
2. Add a timeOut:

setTimeout(function () {
        $('.section').css('height', window.innerHeight + 'px');
        $(window).scrollTop(0);
    }, 50);

1. Additionally we need to listen for window changes. For example on rotation sometimes the toolbar gets hidden. Or if the toolbar is hidden and we tap into top screen and the toolbar shows. Or when opening a new tab in iPhone Plus Landscape or on rotation:

$(window).on('resize', function() {
        $(window).scrollTop(0);
        $('.section').css('height', window.innerHeight + 'px');

        // Additional timeOut for iPhone Plus in landscape with multiple tabs opened
        setTimeout(function() {
            $('.section').css('height', window.innerHeight + 'px');
            $(window).scrollTop(0);
        }, 400);
    });

I added an additional timeOut within the on resize which only affects iPhone Plus with multiple tabs opened(tab bar visible). In this case again window.innerHeight is wrong until an amount of time. 400ms was the minimum i discovered.

With this 3 changes the height stays always perfect.

If not using the option verticalCentered: falsethe height changes needs to be done to .fp-tableCell, too.

[alvarotrigo]

If you find a proper solution feel free to create a PR and I'll review it.
First of all, for what kind of initialisation is the proposed solution? autoScrolling:false? scrollBar:true?

This topic has been treated multiple times, some people suggesting innerHeight, others outerHeight...
None of them ended up convincing me and none of them were fully tested in all devices/OS.

Moreover, this address bar behaviour changes depending on the browser, its version and OS. For example. iPhone 4 or 5 and users have a different behaviour.

Lets not forget also about portrait vs landscape. The latest safari in iPhone 7:

• Won't show the address bar on landscape when coming from a portrait mode.
• Will show it when accessing directly
• Will show it when coming from landscape mode if the cursor was on the address bar
• And of course, it will only show the top address bar, unlike iPhone 4 that will show both top and bottom.

And this is just one single browser in one single OS. I'm sure others might have their funny behaviours too.

I see also you are talking about scrollTop. I guess you were using autoScrolling:false?
This is another point to take into account. The browser (safari) will behave differently depending if you use scrollBar:true or autoScrolling:false (or the responsive mode gets fired), or if you use autoScrolling:true.
The 1st cases will fire the scroll event and the 2nd won't. Which causes the hiding or showing of the scroll bar while scrolling.

And again, when firing the scroll event:

• The address bar gets minified (not hidden) when scrolling down
• The whole address bar is shown again when scrolling up quickly
• A minified address bar is shown when scrolling up slowly

Regarding your pictures, simulators might not be accurate. Can you please use a real device or a connection to one from sites such as browserstack.com. And when doing so, specify the version of iOS you are testing it in?

[MickL]

Hey,

a PR may be appropriate but i don't have the time familiarize with all of fullpage.js right now.

The behavior is not fixed to any setting like autoScrolling:false. It is just a fact that the height of a section (which should be 100% height of viewport) is wrong on any iOS device. In my case i needed to have perfect height to position absolute elements(without using position: fixed which is buggy on iPhone Plus).

I tested my approach on all iOS devices: iPhone 5, 6, 6 Plus with and without tabs. iPhone 5 for example has a exclusive bottombar. Also i tested rotating, adding/removing the tab bar, etc and it seems to work perfectly. This covers all points you mentioned.

I added scrollTop(0) because when you rotate sometimes the iPhone removes the toolbar and leaves a little scroll on the body so it needs to be readjusted to 0. Also the Simulator is very accurate if not 100% like a real device. The OS i used was 10.1.

As I described innerHeight is not always perfect unless using a timeOut. I added fixes for this and an additional fix for iPhone x Plus with toolbar which needs an additional timeOut.

[MickL]

I figured out that the window doesn't always gets updated when the tab-bar comes in/gets removed until a scroll happens. Therefor no resize-event is fired. I needed to add a setInterval using $(window).scrollTop(-1); which updates window if tab-bar came in. I don't see any disadvantages in other browsers. This interval is probably not what you want in your project, but it is the only way to detect and update the real height of the viewport on Mobile Safari.

I tested on iPad Air 2, iPhone 7 Plus (Simulator) and on a Android Marshmallow Phone in Chrome and default browser.

My final script looks like this:

    var height = window.innerHeight;
    var a = setInterval(function() {
        $(window).scrollTop(-1);
        resize();
    }, 500); // Don't lower more than 500ms, otherwise there will be animation-problems with the  Safari toolbar

    $(window).on('resize', function() {
        resize();
    });

    var resize = function() {
        if(window.innerHeight != height) {
            height = window.innerHeight;
            $('.section').css('height', height + 'px');
        }
    };

[MickL]

Just to clearify this:
If you open fullPage.js website on iPhone 7 Plus the section height is set to 414px. But if you type window.innerHeight into console it is 370px without tab-bar and 337px with tab-bar which is the actual viewport. Also verticalCentered: true will not be perfectly centered cause of the wrong height.

[alvarotrigo]

If you open fullPage.js website on iPhone 7 Plus the section height is set to 414px. But if you type window.innerHeight into console it is 370px without tab-bar and 337px with tab-bar which is the actual viewport. Also verticalCentered: true will not be perfectly centered cause of the wrong height.

The site looks good in the demo page as you can see in this screenshoots taken from an iPhone 7:

[alvarotrigo]

I'll mark it as "Reproduction required" as I got no way to reproduce this issue so far.

[MickL]

Sorry I dont have the time to make an live example. I describes every condition and behavior as far as i could.

[MickL]

My fix is also live, field tested and covers all iOS devices if anyone needs to have perfect container heights even after rotating etc.

[Oblik-Design]

same issue here, MickL is right. Innerheight is a safer way in any case.

[MickL]

window.innerHeight is good. But it doesn't delivers the right value from the start. Also following cases change the viewport:

• After Rotation
• Statusbar visible
• Statusbar collapsed (on scroll)
• Bottombar (iPhone 5)
• Tabbar visible (iPhone x Plus)

The problem is that the viewport, readable by window.innerHeight, does not update immediatly. And in some cases it doesn't update at all until there is a scroll (e.g. when the tabbar comes in). Thats why i added all those fixes, timeouts and scrolling to fix all of those problems and different behavior of devices.

If you still dont believe me, here is the proof:

Just open Simulator and try out something. Also you will notice that if you type in window.innerHeight it is the right height while .section and .fp-TableCell is wrong.

Btw. this is the same for pagePiling.js

Maybe i write a blog post about this if i got the time. Also i could write a little script that always gives the right height and you can subscribe to viewport-changes.

[Oblik-Design]

Well it messes up everything on ipad and iphone, maybe, on scroll, change orientation, have the innerheight recalculated, have a look,
www.oblikdesign.com/virgiTest

[Oblik-Design]

And it gets worst if you have a couple of tabs, without tabs and only adress bar, I can live with that, but tabs create a 60 px wiggle room, and fullpage does at one point not land at the right spot.

[MickL]

You can use my final script. Works perfectly in all situations.

[Oblik-Design]

well this gets the site back to -1 everytime I try to scroll with scrollbar: true, Stops craching if false, but stil there is too much height and thing gets miss aligned, it is more obvious, when at the fourth section. Even if everything is right on desktop, everything has overflow, and max-height for each section is 100vh;

[daviddelusenet]

I'm also experiencing this problem on an iPhone 6 with iOS 10. Loading my website in landscape mode breaks often but not every time.

[daviddelusenet]

To give some more context to what I'm experiencing:

I load the website on my iPhone 6 in portrait mode, everything works fine. Then I turn the phone so the website goes into landscape mode. In this mode the nav bar doesn't get shown yet and everything works fine.

As you can see, the top of the text starts at 50% of the section height. Then I toggle the nav bar and this happens:

The logo goes down but the text stays in plays. This is wrong so I decide to reload the page:

The space between logo and text is good now but the alignment is off. So I decide to check out the rendered HTML with my Ghostlab software. Here I find the following things:

So the window.innerHeight displays the right value but the height set in the HTML by FP is not updated and wrong.

[daviddelusenet]

@alvarotrigo we just put a website live were you can reproduce the issue: http://www.momkai.com/

Opening this website on landscape iPhone won't go too well.

[tylerjpeterson]

@alvarotrigo - I recently published a module to retrieve accurate ios window.innerHeight dimensions (orientation-aware, orientation-adaptive) regardless of scroll state. Not certain it's an appropriate fix for this specific issue, but seems like it might be...

npmjs.com/ios-inner-height

[alvarotrigo]

@tylerjpeterson thanks for the info!!
Is it only for iOS ? Have you tested it on Android or other mobile OS?

[tylerjpeterson]

@alvarotrigo - that is a great question! In my limited experience, I haven't run into the issue on Android. Scroll-state-specific window.innerHeight values seem to be unique to iOS. But I'll do some diligence. I do recall reading that Google Chrome may adopt a similar "dynamic" window.innerHeight value in the near future. I'll try to dig up that link as well.

At the moment, the module performs (questionable) user agent matching to only enable dynamic element-based vh measurement for iOS. Otherwise it simply defaults to returning a browser's native window.innerHeight value.

[alvarotrigo]

Thanks I'll play with it whenever I have some time around September.

[marksto]

Hi all!

@alvarotrigo, yep, this issue has reached the Android world too not so long ago. I accidentally stumbled across quite the same behaviour recently on one of my own projects with "100vh"-styled sections. Please, take a look at this blog post by Nicolas Hoizey for the most definitive behaviour description and history.

But the queer thing is the current fullPage's markup doesn't utilize "vh" units. Moreover, AFAICS the Momkai's issue is "height: 100vh !important;" at ".content-section" elements. @daviddelusenet, how 'bout avoiding such styling and simply centering your section's content manually or making html, body and ".pagecontent" styled with "height: 100%; min-height: 100%;"?

So, summing up all above mentioned, @alvarotrigo, you'd better be careful while playing and "fixing" the aforementioned issue on your side. But it's definitely worth it to put a HUUUGE disclaimer on this topic somewherer in a foreground of the fullPage's documentation since this tricky behaviour is getting more and more widespread.

Cheers!

[zebulah]

Hey @MickL thanks for your "final script" -- it is working for us. I'm wondering how you deal with autoscroll. Changing the section heights doesn't seem to percolate through to the autoscroll, so things get misaligned when scrolling. We have some possible solutions, but I'm wondering if you came up with anything. Thanks.

[MickL]

What do you mean by "autoscroll"?

[thisisfed]

The script doesn't fix the annoying problem when browsing through Facebook, Instagram or Twitter browser right?

[zebulah]

@MickL: By autoscroll I mean the way fullpage puts a section into focus in the viewport when scrolling. We just hacked awayand took care of it in a kind of ugly way with this code at the end of the getDestinationPosition function...
.if (isScrollingDown) { position = position + ($(window).height() - window.innerHeight); }
It gets uglier in the minified version.

[bpyrate]

This issue is a total a**hole. The embedded in-app browser functionality destroys sophisticated CSS3 webdesign. However, there seems to be a solution. Look at www.denkwerk.com - they are using FullPage and I figgered out that their website is scalled exactly as it should in the Facebook in-app browser. The sections use the space between the address bar and the navigation bar (bottom) of the Facebook in-app browser (tested with iPhone 6s).

But how did they solve the problem? I tried to figure it out but since I am not that expert you might have a better chance to find the solution that they use.

So check www.denkwerk.com via your Facebook in-app browser (e. g. go to their Facebook Page and follow the link to their website) and see that is working as it should. Next step: investigate how they solved the wrongfull innerheight value issue in the Facebook in-app browser (same problem that appears with twitter, instagram and co)...

Thank you!

[alvarotrigo]

Look at www.denkwerk.com - they are using FullPage

Are they? I don't see any hints of it.

[bpyrate]

But you see that the sections fit perfectly into the in-app browser of Facebook within the Facebook address bar at the top and the Facebook navigation bar at the bottom?

[bpyrate]

How did they manage that the embedded browser bars stay visible while scrolling through the sections?

I found something else: In the embedded browser the window.innerHeight gives the wrong value (screen size instead of viewport). I believe that this is the reason why css height 100% for html and body does not work because it gets the wrong value too.
But if you set an interval (e.g. 5 sec) the window.innerHeight updates to the correct value (screen minus browser toolbars = real viewport). Funny?

[mstrlaw]

@MickL that innerHeight. life saving, thanks!

I ended up using a scroll & resize events instead of the interval to update. First initialize my height variable with window.screen.height and then the scroll even updates it with window.innerHeight.

[thisisfed]

@mstrlaw @MickL can you please share the piece of code that solved your problem? I'd be very happy to try it too.

[MickL]

I did posted my final script at #4

[thisisfed]

@MickL I can't find it there :) There are just some typo fixes.

[Maxim-Mazurok]

@MickL I can't find it there :) There are just some typo fixes.

He meant the 4th reply: https://github.com/alvarotrigo/fullPage.js/issues/2414#issuecomment-261716140

[ckzgraphics]

I am facing the same issue. Somebody suggested to try 'ios-inner-height' NPM Package.