At least some versions of iOS 8 still need this fix

[wargand]

I have an iPhone with IOS 8:
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B440 Safari/600.1.4

With 0.5.0 which claims:

0.5.0 (December 23rd 2014)
WARNING: Breaking Changes (and a Merry Christmas to you, too :)
not engaging the buggyfill on iOS8+ anymore (#19, #23, #27)

I have to use force:
window.viewportUnitsBuggyfill.init({force: true});

Else....see the difference.

[rodneyrehm]

This may be caused by/related to flexbox issues. Can you provide a minimal test case so we can investigate further?

[wargand]

I am not sure if I can. Currently I don't have access to this iPhone. So I am flying somewhat blind here.
I took my original code and removed everything that is not style related. It should behave identical.

Guido

On Mon, 12 Jan 2015 04:52:36 -0800
Rodney Rehm [email protected] wrote:

This may be caused by/related to flexbox issues. Can you provide a minimal test case so we can investigate further?

---

Reply to this email directly or view it on GitHub:
#35 (comment)

[rodneyrehm]

You problem has got nothing to do with viewport units. Upon fixing the following styles in your CSS, the boxes were placed properly:

• margins -> margin
• html, body { height:100%; } -> min-height:100%;
• .footer { position: absolute; bottom: 0; } -> position:static;

the reason is simple position:absolute; bottom:0; accounts for the browser UI (that footer with history navigation, sharing and bookmark buttons), but viewport units do not.

If you agree with the assessment, please close this issue.

[wargand]

Hmm.. it is absolute possible that my css is buggy. It is the very first time I do stuff like that. The only thing I don't understand is, if above assessment really is true, how does viewport-units-buggyfill fix this? Crappy css should be crappy css with our without viewport-units-buggyfill. And with window.viewportUnitsBuggyfill.init({force: true}); it looks like I wanted to look it.

[rodneyrehm]

No clue. For some reason WebKit says the footer is 174.8px tall, iOS Safari 8.1.1 thinks it's 201.02. The buggyfill "fixes this", because it will make the height be 175px (460 * 0.38). I don't know why this is happening. I small test case suggests that you're right about viewport units being borked in iOS8 as well.

Issue #19 was the one reporting that viewport units were fixed in iOS8. Maybe @Euene, @ImBobby, @duranmla and @blowback want to have a look at the test case on their devices? Right now I feel inclined to re-enable the buggyfill on iOS8.

[ImBobby]

I have tried the link in both iPhone 4s and iPad Air running iOS 8.1.2. I added x.style.background = 'red'; to see how it looks visually and visually the viewport unit work just fine. No extra space etc.

But the calculated value is strange. The value of window, clientHeight and the element should be equal right (CMIIW)?

Here's the result:

iPhone 4s 320 x 480 ( device-width )

Portrait

Window	ClientHeight	Element
372px	372px	441px

Landscape

Window	ClientHeight	Element
320px	320px	320px

Ipad Air 768 x 1024 ( device-width )

Portrait

Window	ClientHeight	Element
928px	928px	985px

Landscape

Window	ClientHeight	Element
672px	672px	729px

---

Only in iPhone landscape mode the all the heights are equal.

[ImBobby]

anyway, the viewport unit bug should be fix already. Last December, Apple did bring fix to Safari regarding video playback and I doubt they messed up with the viewport unit.

[rodneyrehm]

But the calculated value is strange. The value of window, clientHeight and the element should be equal right (CMIIW)?

yes, they should. At least they are on other browsers. That's what got me stumped :/

[ImBobby]

Very strange indeed. I have been using viewport unit in some projects, tested in iOS8 and didn't have any issue. I mean, visually the site was not broken. It turned out as expected.

Should we wait for another test case?

[nhoizey]

I have the same issue on iOS 8.1.3 on an iPhone 5 and an iPad 2.

The interface (URL bar, tabs) is part of a 100vh height. The real viewport is more arround 90vh (depends on portrait or landscape view).

When added to the home screen, it works well if <meta name="apple-mobile-web-app-capable" content="yes" /> because there is no interface anymore, the web app is full screen.

[rodneyrehm]

I think I figured out what the "problem" is. window.innerHeight shows the real space currently available (full height of viewport - height of browser UI) while 100vh always maps to full height of viewport. a resize event is dispatched when the browser UI is shown/hidden. test case.

I'm not sure if the buggyfill should do anything about this?!

[ImBobby]

according to the specification

Note that the initial containing block's size is affected by the presence of scrollbars on the viewport.

That means 100vw is actually full width of browser - scrollbar width and 100vh is equal to
window.innerHeight right?

[dmjendor]

This issue still occurs when doing using the the embedded web browser control in an IOS app. Without the buggyfill running we see problems where the embedded keyboard control will re-size the window when an input is edited, but the elements don't redraw. It works correctly in Safari, but not in the embedded browser. If I force the buggyfill to initialize, the embedded browser then also works properly.

[rodneyrehm]

Are you talking about the native keyboard, or something the host app made available?

[dmjendor]

yeah, when the native keyboard is opened up within the app it appears to open as part of the page rather than over the top of it. Elements on the page that use VH get altered to try and fit the new height, but when the keyboard is dismissed they do not update again to the full view height.

It appears to be specific to the embedded browser control as the issue does not occur in Safari on the same iPod. Right now I am working around it by using the force=true option on init when its userAgent is the iOS webkit.

[rodneyrehm]

yeah, when the native keyboard is opened up within the app it appears to open as part of the page rather than over the top of it. Elements on the page that use VH get altered to try and fit the new height, but when the keyboard is dismissed they do not update again to the full view height.

Is there a specific app this can be reproduced with? I've never experienced that behavior before…

It appears to be specific to the embedded browser control as the issue does not occur in Safari on the same iPod. Right now I am working around it by using the force=true option on init when its userAgent is the iOS webkit.

Which is pretty much what I'm doing as well - for other reasons, but that approach is fine!

[robertfausk]

Referring http://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html#march-4th-update apple says that "this issue behaves as intended".
That means 100vh are higher than the visible part of the window.

I suggest reenable support for ios 8.

[nhoizey]

Still true in iOS 9… :-/

[rodneyrehm]

I give up on this… enabled for iOS8 and iOS9 by #67

[nhoizey]

Thanks!