Firefox/Gecko 控件干扰 Windows 窗体按键
编辑:除了赏金之外,我们还愿意支付 250 美元来修复 Firefox/Gecko 代码库中的此错误。 这里是一个简单的测试项目 (Visual Studio 2008 C#),它重现了该问题。
编辑#2我们愿意支付 600 美元来修复此错误。 请参阅上面重现问题的示例项目。
我们的 C# Windows 窗体上有一个 Firefox (Gecko) ActiveX 控件来显示 HTML。
当这个 Firefox ActiveX 控件位于我们的表单上时,大约 2-3% 的按键无法通过。 或者更确切地说,发送了一条不同的 Windows 消息:
我们按住 TAB 键以 Tab 键浏览 3 个常规 WinForms 文本框。 97% 的情况下它都会正确运行。 Spy++ 告诉我们 WM_KEYDOWN 消息已正确发送:
正常行为 http://judahhimango.com/images/normaltab.jpg
但随机地,可能有 2-3% 的时间,Tab 键(或其他键)未正确处理。 Spy++ 告诉我们正在发送 WM_CHAR:
奇怪的行为 http://judahhimango.com/images/screwytab.png
当奇怪的行为发生时,要么根本没有处理该键,要么处理不正确(例如在不支持制表符的文本框中插入“\t”字符。
只有当 Firefox ActiveX 控件在我们的表单上。
我们的问题是:Firefox/Gecko 引擎是否安装了某种可能导致这些副作用的键盘挂钩?或者更好的是,我们如何解决此问题?
Edit: In addition to the bounty, we're willing to pay $250 to have this bug fixed in the Firefox/Gecko codebase. Here is a simple test project (Visual Studio 2008 C#) that reproduces the problem.
Edit #2 we're willing to pay $600 to have this bug fixed. See above for sample project that reproduces the problem.
We have a Firefox (Gecko) ActiveX control on our C# Windows Form to display HTML.
When this Firefox ActiveX control is on our form, about 2-3% of our key presses don't make it through. Or rather, a different Windows message is sent:
We hold down the TAB key to tab through 3 regular WinForms text boxes. It will behave correctly 97% of the time. Spy++ tells us WM_KEYDOWN message is sent properly:
normal behavior http://judahhimango.com/images/normaltab.jpg
But randomly, maybe 2-3% of the time, the tab key (or other key) isn't processed right. Spy++ tells us WM_CHAR is being sent instead:
odd behavior http://judahhimango.com/images/screwytab.png
When the odd behavior occurs, either the key is not processed at all, or is processed incorrectly (such as inserting a '\t' character into a textbox that doesn't support tab characters.
This only occurs if the Firefox ActiveX control is on our form.
Our question is: does Firefox/Gecko engine install some kind of keyboard hook that might cause these side effects? Or better yet, how do we fix this problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
WM_CHAR 消息是由 TranslateMessage 调用生成的,因此最好从 Gecko 源代码中的 TranslateMessage 调用开始查找。
在您提供的第一个示例代码中,该函数仅由两个库导入 - mozctl.dll 和 xul.dll。 既然您声称 GeckoFX 也会发生同样的错误,我们可以将 mozctl.dll 排除在外。 这给我们留下了 xul.dll,因此鉴于 Gecko 源代码,我建议查看
widget\src\windows\nsToolkit.cpp
。 我不确定如果嵌入了引擎,代码是否会运行,但如果是,则库会在不同的线程中启动一个全新的消息泵,这必然会中断。不幸的是,我无法在我的机器上运行或编译代码(Windows 7 x64,未安装 Mozilla ActiveX 控件),因此我无法使用调试器验证其中的任何内容。 希望它可以帮助有人进一步追踪它。
The WM_CHAR message is generated by TranslateMessage call, so a good place to start looking would be the TranslateMessage calls in the Gecko source code.
In the first example code you provided the function is imported only by two libraries - mozctl.dll and xul.dll. Since you claim that the same error happens also with GeckoFX we can take mozctl.dll out of the equation. That leaves us with xul.dll, so given the Gecko source code I would suggest to look into
widget\src\windows\nsToolkit.cpp
. I am not sure if the code is run if the engine is embedded, but if it is then the library starts a whole new message pump in different thread, which is bound to break.Unfortunately I can't run or compile the code on my machine (Windows 7 x64 w/o the Mozilla ActiveX control installed), so I can't verify any of this with a debugger. Hope it helps someone to track it down further.
根本问题是,当 Mozilla 嵌入到另一个应用程序中时,它在分派内部事件时会错误地泵送 Windows 消息。 Mozilla 使用事件系统来跨线程协调或安排线程上的延迟处理(请参阅 nsIThread ,nsIEventTarget)。 例如,如果您嵌入了一个包含大量活动 XMLHTTPRequest 的网页,Mozilla 将使用其事件分派接口将事件分派回 JavaScript,并且作为副作用,它将泵送 Windows 消息。 一旦 Mozilla 事件完全分派,它就会返回到主事件循环。
当 Mozilla 泵送 Windows 消息时,它不包括应用程序事件循环完成的额外处理 - IsDialogMessage()、TranslateMessage()、PreTranslateMessage() 或当 Mozilla 进入此状态时跳过任何其他预处理。 因此,症状包括按 Tab 键作为字符插入而不是用于对话框导航、偶尔忽略键盘热键或偶尔跳过自定义消息预处理。 例如,Outlook 2007/2010“撰写”屏幕偶尔会丢失击键,因为它依赖于自定义消息预处理来处理键盘输入。
请参阅https://bugzilla.mozilla.org/show_bug.cgi?id=582790 获取解决该问题的补丁。
The root problem is that when Mozilla is embedded in another application, it incorrectly pumps Windows messages when it dispatches internal events. Mozilla uses an event system to coordinate across threads or to schedule deferred processing on a thread (see nsIThread, nsIEventTarget). If you embed a web page with a lot of active XMLHTTPRequests, for example, Mozilla will use its event dispatching interface to dispatch events back to javascript and it will pump windows messages as a side effect. Once Mozilla events are fully dispatched, it goes back to the main event loop.
When Mozilla pumps windows messages, it doesn't include the extra processing done by the application's event loop - IsDialogMessage(), TranslateMessage(), PreTranslateMessage(), or any other pre-processing are skipped when Mozilla gets into this state. Symptoms therefore include tab key presses getting inserted as a character instead of being used for dialog navigation, keyboard hotkeys being sporadically ignored, or custom message pre-processing being sporadically skipped. For example, the Outlook 2007/2010 "Compose" screen sporadically loses keystrokes because it relies on custom message pre-processing to handle keyboard input.
See https://bugzilla.mozilla.org/show_bug.cgi?id=582790 for a patch that addresses the problem.
我有 Snoop Free 和 PSM Anti-Keylogger。
其中之一检测到 Firefox 试图安装键盘挂钩。
Mozilla/Firefox 文件 xul.dll 尝试在键盘挂钩上安装。
拒绝了。
I have Snoop Free and PSM Anti-Keylogger.
One of them detected firefox trying to install a Keyboard Hook.
Mozilla/Firefox file xul.dll attempt at installing at keyboard hook.
DENIED.
我注意到您已经自己实现了所有互操作性。 您可以在 GeckoFX 项目中尝试一下,看看是否遇到相同的错误? 我在工作中使用这个项目,还没有遇到任何问题。
I noticed that you have implemented all of the interoperability yourself. Can you try this with the GeckoFX project and see if you get the same error? I use this project at work and haven't encountered any issues yet.