[webkit-dev] Hi All (Windows WebKit through COM, focus issue)

[Mike]

I just joined this list, so hopefully I'm not intruding...

I recently started work on making a lightweight browser for WebKit on
Windows through COM+.NET, which actually has been a great success. I'm
happy to report that I'm able to use the latest nightly build (r39553)
from within a .NET Windows Form.  I don't mind publishing the wrapper
in the future to help further the development of WebKit, but I'm
having an issue which is preventing me from moving forward...

To sum it up the best I can, if I have a WebView on a form, and I call
"setHostWindow" with that form's handle, I experience no behavioral
issues. If I create a panel on the form, and I use that as the host
handle, the WebView works as designed.
But, if I create a tab control and add multiple tab pages, and use
panels on those tabs to host the control, when the form is active, the
WebView does not act as if it is active (it doesn't display the cursor
for text boxes and other fields, and the safari theme for the scroll
bar does not light up).

The first tab page works properly, but the other tab pages display
this behavior.

Example of appropriate behavior on the first tab... form is active,
control shows proper focus
http://img49.imageshack.us/img49/9758/example1rc5.jpg

The second tab, when it's active (and the form is active), the WebView
control doesn't show proper focus, and the text box does not show the
focus ring correctly either...
http://img530.imageshack.us/img530/4653/example2tg6.jpg

I think the easiest way to fix this problem, would be to allow manual
control of the "active state" of the WebView control through the COM
interface. Manually setting the state through events that fire on the
Windows forms would be an incredibly easy task. But, I'm not sure how
difficult it is to change the base code (if there's a lot of hoops to
jump through), or whether or not it's actually appropriate to solve
this problem in that manner...

Either way, I would appreciate it a lot if someone got back to me.
I've been trying to figure out how to get around this issue for the
last couple days (even tried manually sending signals to the control
via the windows API), but I haven't been able to get anything working
yet.

Thanks for reading,
Mike