Possible bug in resetActivePageHeight #7322

Closed
gabrielschulhof opened this Issue Apr 15, 2014 · 29 comments

Projects

None yet

2 participants

@gabrielschulhof
Contributor

http://jsbin.com/IFolanOW/391/

Steps to reproduce:

  1. Open URL in plain old Safari
  2. Click on the first input (VKB pops up)
  3. Scroll to the bottom of the page
  4. Scroll to the top of the document
  5. Click on the second input
  6. Scroll to the bottom of the document

Sometimes the bottom of the page does not coincide with the bottom of the document. I painted the page pink to make the difference visible.

Please also repeat the steps after having added the above URL as an app to your home screen and see if you get the error under those circumstances.

@gabrielschulhof
Contributor

iOS 6.1.x

@gabrielschulhof
Contributor

WP8 - much, much worse

@arschmitz
Member

seems fine in iOS 7

@gabrielschulhof
Contributor

@arschmitz Have you tried both in the browser and as a fullscreen app?

@arschmitz
Member

no this issue does not mention fullscreen

@gabrielschulhof
Contributor

Good point! I'll add it to the description.

@arschmitz
Member

i don't see anything in fullscreen either though

@gabrielschulhof
Contributor

@arschmitz In fact, it seems that fullscreen mode on iOS 7 is the only one that works correctly. By that I mean that, when the vkb pops up, the page actually becomes shorter so that no scrolling is necessary even with the vkb up. This is what should be happening on all platforms since, even with the vkb up, the viewport is sufficiently tall to accommodate the button and the two text inputs.

@arschmitz
Member

no thats not what it does on iOS 7 the page height does not change based on
the keyboard at all. you can scroll when the keyboard is up but not when its hidden. This is how it should be the virtual keyboard slides over the page it does not push the page up.

@gabrielschulhof
Contributor

@arschmitz Is this not what you're seeing on fullscreen iOS7?

@gabrielschulhof
Contributor

IOW, the page is not tall enough to scroll when there's no VKB, and it's also not tall enough to scroll when there's a VKB on screen. Actually, I should set a border on the page to see whether the page is behind the VKB, or whether the viewport is actually reduced.

@arschmitz
Member

the viewport is reduced this is why fixed elements slide up with the keyboard

@gabrielschulhof
Contributor

Yes, the viewport is reduced, and the page height reflects the new viewport height. Not so anywhere else.

@gabrielschulhof
Contributor

Everywhere else, the page height is set such that, when the vkb is up, the page can be scrolled.

@arschmitz
Member

i cant view your video

@gabrielschulhof
Contributor

Grrr! I'll youtube it.

@arschmitz
Member

the video is private

@gabrielschulhof
Contributor

Oh, fer cryin' out-loud.

@gabrielschulhof
Contributor

Should be good now.

@gabrielschulhof
Contributor

@arschmitz Look at http://jsbin.com/IFolanOW/392/ in the browser vs. fullscreen. In the browser, after the vkb pops up, the page goes on behind the vkb, whereas in fullscreen, the page is resized to the new viewport.

I need to figure out if, in the browser, the page has the size it has because there's no resize event, or, because we're setting the height to the former viewport height in resetActivePageHeight.

@gabrielschulhof
Contributor

I mean, look at it on iOS 7.

@gabrielschulhof
Contributor

OK, on iOS 7 Safari, the browser does not tell us that the VKB has appeared. On iOS 7 fullscreen, the browser tells us that the viewport is now smaller and we correctly compensate. If you switch between the inputs while the VKB is active, nothing happens.

@gabrielschulhof
Contributor

On iOS 6 Safari, you click on the first input, the vkb appears, and no resize events happen. But, if you click the second input while the VKB is up, you get a pile of resize events, and you keep getting them long after the second input has received focus and things appear quiescent. The final two resize events have the same size, so it appears that the viewport is slowly approaching that size. If you dismiss the vkb, you get another resize but now your page height is such that it fits only if the location bar is visible. IOW, iOS 7 is much saner.

@gabrielschulhof
Contributor

iOS 6 fullscreen is saner too. It simply doesn't issue any resize events whatsoever in response to vkb appearance/disappearance.

@gabrielschulhof
Contributor

OK, so it seems on iOS 6 Safari and on WP8 (at least), when we resize the page to the height of the viewport, /something/ is causing the document to be taller than the page, causing scrolling.

@gabrielschulhof
Contributor

More steps to reproduce:

  1. Open http://jsbin.com/novifoba/4 and observe whether any elements are listed in the debugging output. The height of those elements exceeds the page height.
  2. Click on the first input
  3. Click on the second input

On WP8 and iOS 6 you will find that there are instances when the HTML and the BODY exceed the page height. There's no reason for this, since the only box inside the HTML is the body, and the only box inside the body is the page.

@gabrielschulhof gabrielschulhof changed the title from iOS: Possible bug in resetActivePageHeight to Possible bug in resetActivePageHeight Apr 15, 2014
@gabrielschulhof
Contributor

For the record: Android (2.3.5 physical, 4.0 and 4.4.2 emulated) is rock-solid in this regard. It always resizes the window when the vkb appears, and there are never any "stragglers" - i.e., elements whose height exceeds the viewport size.

@gabrielschulhof
Contributor

WP7.5 also works surprisingly well.

@gabrielschulhof gabrielschulhof added a commit that referenced this issue Apr 16, 2014
@gabrielschulhof gabrielschulhof Helpers: Make resetActivePageHeight() less aggressive
Do not set min-height if the existing height is good enough.
This fixes iOS 6.1, but not WP8.

Fixes gh-7322
3cdf7c8
@gabrielschulhof gabrielschulhof self-assigned this Apr 16, 2014
@gabrielschulhof gabrielschulhof added a commit that closed this issue Apr 24, 2014
@gabrielschulhof gabrielschulhof Helpers: Make resetActivePageHeight() less aggressive
Do not set min-height if the existing height is good enough.
This fixes iOS 6.1, but not WP8.

Closes gh-7325
Fixes gh-7322
459bb59
@gabrielschulhof gabrielschulhof added a commit that referenced this issue Apr 24, 2014
@gabrielschulhof gabrielschulhof Helpers: Make resetActivePageHeight() less aggressive
Do not set min-height if the existing height is good enough.
This fixes iOS 6.1, but not WP8.

(cherry picked from commit 459bb59)

Closes gh-7325
Fixes gh-7322
5f2dd7e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment