当我为调整大小事件分配一个超时的处理程序时,为什么它会不断触发?
我为 window.resize 处理程序分配了一个超时,这样我就不会在每次调整大小事件触发时调用大量的调整大小代码。 我的代码如下所示:
<script>
function init() {
var hasTimedOut = false;
var resizeHandler = function() {
// do stuff
return false;
};
window.onresize = function() {
if (hasTimedOut !== false) {
clearTimeout(hasTimedOut);
}
hasTimedOut = setTimeout(resizeHandler, 100); // 100 milliseconds
};
}
</script>
<body onload="init();">
...
etc...
在 IE7(可能还有其他版本)中,当您执行此操作时,调整大小事件将不断触发。 更准确地说,它会在每次超时持续时间(本例中为 100 毫秒)后触发。
有什么想法为什么或如何阻止这种行为吗? 我真的不想为在单个调整大小中触发的每个调整大小事件调用我的调整大小代码,但这更糟糕。
I assigned a timeout to my window.resize handler so that I wouldn't call my sizable amount resize code every time the resize event fires. My code looks like this:
<script>
function init() {
var hasTimedOut = false;
var resizeHandler = function() {
// do stuff
return false;
};
window.onresize = function() {
if (hasTimedOut !== false) {
clearTimeout(hasTimedOut);
}
hasTimedOut = setTimeout(resizeHandler, 100); // 100 milliseconds
};
}
</script>
<body onload="init();">
...
etc...
In IE7 (and possibly other versions) it appears that when you do this the resize event will constantly fire. More accurately, it will fire after every timeout duration -- 100 milliseconds in this case.
Any ideas why or how to stop this behavior? I'd really rather not call my resize code for every resize event that fires in a single resizing, but this is worse.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
在您的 //do stuff 代码中,您是否操作任何 top、left、width、height、border、margin 或 padding 属性?
您可能无意中触发了递归,这无意中触发了递归,这无意中触发了递归......
In your //do stuff code, do you manipulate any of the top,left,width,height,border,margin or padding properties?
You may unintentionally be triggering recursion which unintentionally triggers recursion which unintentionally triggers recursion...
如何修复 IE 中的调整大小事件
另外,请参阅“scunliffe”的答案“在您的...属性中?
How to fix the resize event in IE
also, see the answer for "scunliffe" "In your ... properties?
IE 在调整大小时确实会不断触发其调整大小事件(您必须知道这一点,因为您已经实施了超时修复)。
我可以使用您的代码在我的测试页上复制您所看到的结果。
但是,如果我将超时增加到 1000 而不是 100,问题就会消失。您可能需要尝试使用不同的等待值,看看哪种方法适合您。
这是我使用的测试页面:它已经有一个很好的动态等待期设置给你玩。
IE does indeed constantly fire its resize event while resizing is taking place (which you must know, as you are already implementing a timeout for a fix).
I am able to replicate the results you are seeing, using your code, on my test page.
However, the problem goes away if I increase the timeout to 1000 instead of 100. You may want to try with different wait values to see what works for you.
Here is the test page I used: it has a nicely dynamic wait period already set up for you to play with.
我偶然发现了同样的问题,但以不同的方式解决了它,我认为这比超时更优雅......
上下文:我有一个 iframe 页面,加载到父页面内,并且 iframe 必须通知父页面大小发生变化,因此父级可以相应地调整 iframe 的大小 - 实现 iframe 的动态调整大小。
因此,在 iframed HTML 文档中,我尝试在 body 标记上注册回调。 首先,在 onchange 上 - 它不起作用。 然后在调整大小时 - 它确实有效,但不断发射。 (后来我找到了原因 - 这显然是 Firefox 中的一个错误,它试图将我的页面扩展到无限)。 我尝试了 ResizeObserver - 无济于事,同样的事情发生了。
我实现的解决方案是这样的:
那么它是如何工作的:每次回调触发时,我们都会增加一个变量 v; 每 300 毫秒,我们将其递减一次; 如果太大,射击就会受阻。
与基于超时的解决方案相比,它的一大优点是它引入了用户体验的滞后,并且还清楚地表明它到底如何阻止递归。 (嗯,实际上不是)))
I stumbled on the same problem, but solved it differenly, and I think it's more elegant than making a timeout....
The context: I have an iframed page, loaded inside the parent page, and the iframe must notify the parent when its size changes, so the parent can resize the iframe accordingly - achieving dynamic resizing of an iframe.
So, in the iframed HTML document, I tried to register a callback on the body tag. First, on the onchange - it didn't work. Then on resize - it did work, but kept firing constantly. (Later on I found the cause - it was apparently a bug in Firefox, which tried to widen my page to infinity). I tried the ResizeObserver - for no avail, the same thing happened.
The solution I implemented was this:
So how it works: each time the callback fires, we increment a variable v; once in every 300 ms, we decrement it; if it's too big, the the firing is blocked.
The big advantage of this over the timeout-based solution, is that it introduces to lag for a user experience, and also clear in how exactly it does block the recursion. (Well, actually not )))