Element.offsetHeight for a position-fixed element returns incorrect values after window resize event
Reported by
msamkiru...@gmail.com,
Dec 3
|
||||
Issue descriptionSteps to reproduce the problem: 1. Open test.html in iOS Chrome. 2. Scroll the page(Toggle between URL Bar visible and hidden mode). 3. Watch the height of the position-fixed-div written on the left pane(which is the position-fixed-div). 4. Try to scroll(touch move) with different momentum. What is the expected behavior? (What you see on the left as you scroll): [x:::y] x - height of the div when the resize event is triggered. y - height of the div 2 seconds after the resize was triggered. I tested in iPhone 5C. So, i get 2 heights 452 - when the URL bar and the bottom-tool bar are visible and 528 - when the URL bar and bottom-tool bar are hidden. Understanding that iOS triggers the resize event even when the resize is in progress, x can go wrong. But, y should be correct always - 2 seconds delay should be enough for this small page(I have tested with 5 seconds also). So when the URL bar is shown, the following combinations are valid(in iPhone 5C - only the values must change for different device anyway). [452:::452] or [528:::452]. When the URL bar is hidden, [528:::528] or [452:::528] are valid. What went wrong? Value of y is going wrong. [Watch the video test-position-fixed.mp4] - First row of values in the video is correct. - Second row is completely wrong. Should have been [452:::452]. Or atleast [something:::452]. But it shows [528:::528]. I'm pretty sure that the delay is quite enough. Even 5 seconds shows the same result. - Third row is correct. - Fourth row is partially correct -acceptable. NOTE: Momentum of the touch move action in 2nd row and the 4th row are different. It's not so easy to reproduce always. But, it happens and is unacceptable. Did this work before? No Does this work in other browsers? Yes Chrome version: 70.0.3538.75 Channel: stable OS Version: 10.3.3 Flash Version: I'm observing this incorrect behaviour only for elements with position value as fixed. I need the value to be fixed for many reasons -and I'm not going to change.
,
Dec 6
,
Dec 6
,
Dec 6
Hi msamkirubaharan@. We've updated the way in which we resize the viewport when the toolbars are being shown/hidden. I've checked against the new implementation using your test page, and everything seems to be updating properly. This fix is rolling out starting with the M71 version of Chrome iOS, and is initially available to 1% of M71 users before rolling out to the rest of our users. That being said, this fix will only be available on iOS12 and above, so you don't be able to test this on your iPhone 5C. Unfortunately, limitations on WKWebView's API in iOS11 and earlier prevent this fix from being rolled out to those users.
,
Dec 7
Hi @kkhorimoto, Thanks for the reply. As you would expect I'm not targeting only the latest version of Chrome. So is there a hack to get it right in the previous versions of iOS Chrome.
,
Dec 7
Unfortunately, I'm not aware of any workarounds for this issue. We'd spent some time trying to get fixed-position elements to be rendered properly with the toolbar resizing that occurs, but the only way we found to reliably do it is the iOS12 fix I mentioned earlier.
,
Dec 10
@kkhorimoto Thanks for the information. |
||||
►
Sign in to add a comment |
||||
Comment 1 by msamkiru...@gmail.com
, Dec 4