iOS Chrome计算出错误的文档高度 [英] iOS Chrome calculates the wrong height of the document
问题描述
为了填充整个页面的高度，我对HTML和body标签使用 height:100％; ，在关闭浏览器并重新打开之前，它可以正常工作.(由于移动设备上的问题 https://angelika94.github.io/rick/(您会看到导航(Morty和Beer)位于页面底部) css的屏幕截图导航里克
在以下情况下，页面将自行修复:
- 更新页面
- 将设备旋转到横向
- 通过标签打开和关闭浏览器的导航
- 关闭并重新打开浏览器，而不用在多任务导航中关闭它
为什么会发生?如何解决此问题?
提前谢谢！
我遇到了一个非常不同的问题，但是我认为我制定的解决方案也可能适合您的情况，因为您提到更新页面可以解决该问题./p>
所以我在chrome上遇到了问题，如果您快速滚动(在移动设备上并不罕见)，某些元素将无法重新绘制.在各处搜索解决方案，但找不到任何可行的方法.
最后，我找到了一个可行的解决方案:
.pagewrap {转换:translateZ(0);animation-name:重新绘制"；动画时间:3秒；animation-iteration-count:无限；animation-play-state:正在运行；动画定时功能:线性；}@keyframes repaint {from {缩放:99.99999％;}至{缩放:99.99998％；}} 因此，这将迫使页面在3秒的周期内不断重新绘制.
也许我应该调整它，使其每2秒仅移动一秒钟的时间，而不是连续移动:
.pagewrap {转换:translateZ(0);animation-name:重新绘制"；动画时间:2秒；animation-iteration-count:无限；animation-play-state:正在运行；动画定时功能:线性；}@keyframes重绘{0％{变焦:99.99999％;}99％{变焦:99.99999％;}100％{变焦:99.99998％;}} 我尝试了 zoom:99.99999; 到 1 ，但是某些在某些悬停效果上缩放比例超过1的元素会显示缩放呼吸.所以99.99999到99.99998使我看不到效果.
稍有漏洞的解决方案，可能会在很长的页面上出现性能问题，但可能不会，因为浏览器只应呈现屏幕上的内容.我在上面使用的页面在图形上很繁琐，并具有许多复杂的多层效果，并且似乎对性能没有明显影响.
似乎许多移动浏览器的渲染效果都过分优化，这导致古怪的失败，而没有记录在案的修复程序.强制重涂是我发现的唯一可行的解决方法.
我尝试了其他方法，但没有那么积极地记录在案的强迫重涂方法.就像在滚动停止200ms之后向页面中添加一些文本(不可见)等.但是什么都没做，所以我的动画整个页面永远都被破解了.
就您而言，其他一些黑客可能会更好地工作.文章概述引起重绘/重排的所有各种原因，因此您可以尝试通过脚本执行其中的一些事情.
In order to fill the whole height of the page, I use height: 100%; for html and body tags,
and it works fine until a browser would be closed and reopened.
(I don't use 100vh because of issues on mobile devices https://nicolas-hoizey.com/2015/02/viewport-height-is-taller-than-the-visible-part-of-the-document-in-some-mobile-browsers.html )
Steps to reproduce:
- Open https://angelika94.github.io/rick/ in Google Chrome on iPhone (you will see that navigation (Morty and Beer) is placed on the bottom of the page) screenshot of css Rick with navigation
- close the browser and remove it from multitasking navigation: https://support.apple.com/en-us/HT201330
- open the browser again (you will see that bottom navigation moved off the "first screen" and now you need to scroll to see it) screenshot of css Rick without navigation
the page will be fixed by itself in these cases:
- update page
- rotate the device to landscape
- open and close browser's navigation by tabs
- close and reopen browser without closing it in multitasking nav
Why does it happen? How can I fix this behavior?
Thank you in advance!
I had a very different issue, but I think the solution I worked out may work for your situation also, because you mentioned updating the page would fix it.
So I had issues with chrome on android where if you scroll very quickly (not uncommon on mobile), some elements would fail to get re/painted. Searched everywhere for a solution but couldn't find anything that would work.
Finally, I figured out a working fix:
.pagewrap {
transform: translateZ(0);
animation-name: 'repaint';
animation-duration: 3s;
animation-iteration-count: infinite;
animation-play-state: running;
animation-timing-function: linear;
}
@keyframes repaint {from { zoom: 99.99999%; } to { zoom: 99.99998%; }}
So what this does is forces the page to continually repaint on a 3 second cycle.
Maybe I should tweak it to only shift for a fraction of a second every 2 seconds, instead of continually:
.pagewrap {
transform: translateZ(0);
animation-name: 'repaint';
animation-duration: 2s;
animation-iteration-count: infinite;
animation-play-state: running;
animation-timing-function: linear;
}
@keyframes repaint {
0% {
zoom: 99.99999%;
}
99% {
zoom: 99.99999%;
}
100% {
zoom: 99.99998%;
}
}
I tried zoom: 99.99999; to 1 but certain elements that transitioned scale above 1 on some hover effects would show the zoom breathing. So 99.99999 to 99.99998 was what worked for me to make the effect invisible.
Slightly hacky solution that could present performance issues for very long pages, but maybe not, because the browser should only be rendering what's onscreen. The pages I used this on are graphically heavy with a lot of complex multi-layer effects, and this doesn't seem to have a noticeable performance impact.
Seems like many mobile browsers have excessively optimized rendering, which leads to quirky failures with few well documented fixes. Forcing repaints was the only working fix I found.
I tried other, slightly less aggressive, documented methods of forcing repaints. Like adding some text to the page (invisibly) after scrolling stops for 200ms, and such. Nothing worked though, thus my animate-the-entire-page-forever hack.
In your case, some of those other hacks may work better. This article outline all the various things that cause repaints/reflows so you could try doing some of these things via script.
这篇关于iOS Chrome计算出错误的文档高度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
