I suffered similar situation some days ago. I wish I can help you. "WebKit Windows port" calls SetCapture() in WM_LBUTTONDOWN handler of WebViewWndProc(). If you call ReleaseCapture() in proper position, I think, you may solve your problem.
I used r39476 of "WebKit Windows port". And in that revision, the position of ReleaseCapture() call was somewhat wrong. I moved ReleaseCapture() call to the very first line of WM_LBUTTONUP handler code and solved my problem. Good Luck~ Mike-649 wrote: > > 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 > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > -- View this message in context: http://www.nabble.com/Hi-All-%28Windows-WebKit-through-COM%2C-focus-issue%29-tp21273592p24934802.html Sent from the Webkit mailing list archive at Nabble.com. _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
