Search code examples
winformsfirefoxhookgeckowindow-messages

Firefox/Gecko control interfering with Windows Forms key presses


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?


Solution

  • 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.