在 IE 中延迟处理 WM_TIMER 是否安全？答案

【问题标题】：safe to delay processing of WM_TIMER in IE?在 IE 中延迟处理 WM_TIMER 是否安全？
【发布时间】：2011-05-04 18:19:24
【问题描述】：

我们有一个 activex 控件，它需要在阻塞时发送 win32 消息以保持 IE 响应。为了避免一些由 activex 引入的真正令人讨厌的 javascript 问题，我们希望从我们的 activex 控件的 win32 消息泵中跳过 WM_TIMER 消息，当 IE 的消息泵重新获得控制权时，IE 可以处理它们。

这行得通，但我绝对害怕以这种方式与 IE 内部组件混为一谈，如果我们选择继续，预计会出现随机的不可重现的故障，当然也不指望未来可以证明。我们正式支持 IE7+。 IE6 兼容性很好，但我们已经有了一个适用于所有 IE 版本的迂回解决方法。

我认为这种方法实际上可能合理的唯一原因是 IE 开发人员工具 javascript 调试器中的断点似乎会停止整个进程，这意味着延迟 WM_TIMER 消息并没有完全搞砸，至少在 IE8 中是这样。

如果我在下载 1GB 文件时将消息延迟半小时怎么办？

【问题讨论】：

由于首先无法保证 WM_TIMER 消息的传递时间，我想你会没事的，FWIW。

标签： windows winapi internet-explorer com activex

【解决方案1】：

WM_TIMER 消息是“低优先级”消息，无论如何都不能保证按时传递 - 您必须注意的是计时器消息是否用于执行 IE 的延迟初始化 - 如果您等待为了让 IE 在退出循环之前进入某种状态，被禁止的消息可能会导致进程死锁。

除此之外，模式消息循环的重点是启用这种过滤。

【讨论】：

如果我在下载 1GB 文件时将消息延迟半小时怎么办？
那么随机脚本在 30 分钟内不会触发。渲染体验有些不可靠。这一切都取决于正在显示的网页。

【解决方案2】：

你到底为什么要这样阻塞 IE 线程？我知道有时甚至需要丑陋的黑客，但我很难想象。如果是我，我会改为在 DOM 中触发一个 javascript 事件，让页面知道发生了什么，并以优雅的方式处理被意外关闭的控件。

除此之外，不要占用 IE 进程，而是启动另一个进程。如果您在安装期间注册它，您可以从 ActiveX 控件内部启动中等完整性进程。无论哪种方式，您的 activex 控件都可以在它在另一个线程（或进程）中运行时对其进行跟踪，并且您可以使用跨线程或进程间同步和通信来跟踪正在发生的事情。

【讨论】：

我们扩展的activex产品是一个文件下载器，它公开了一个阻塞的Download()方法。即使它阻塞了，它也会打开窗口，所以 IE 仍然响应点击并且 JS 可以重新调用控件。听起来很老套，但确实感觉作者知道他在做什么......
我认为要求是相同的进程，以便控件（通过 WinINET）可以发送带有 IE 上下文和 cookie 等内容的请求。
您可以在没有阻塞方法的情况下异步执行此操作； FireBreath 使用 WinINET 进行下载，并以浏览器友好的异步方式处理所有内容。我会非常非常强烈地建议不要阻止。我很确定您仍然可以在不同的过程中执行此操作，但我认为您没有任何理由需要这样做。如果劫持 winproc 似乎可行，您可能可以做到……但您永远无法确定不会有负面影响。即使现在有，也可能会有所改变。