Hi Vincent and Mark: On Sep 13, 2013, at 1:06 AM, Salisbury, Mark <mark.salisb...@hp.com> wrote:
> Vincent, > > Maybe some tips I’ve learned could be of help to you or others: > · Calling DestroyWindow will cause WebView::close() to be called (when > WM_DESTROY is received), but it does not cause WebView’s destructor to be > called, that doesn’t happen until the RCW holding the last COM reference is > destroyed and the COM ref count goes to 0. This happens on the GC thread > (.NET internals), and deleting core webkit objects from a thread besides the > main thread can lead to undefined behavior. I’d see crashes from concurrent > javascript GCs. I fixed this by marshaling the delete call back to the main > thread (in every single COM exposed class). I’m not sure this is limited to WebKit, or .NET. I think destroying any GDI or other “User Interface” content outside of the main thread causes bad things to happen. I’ve seen this with MFC and base WinAPI programs as well. To be fair, Mac OS has a number of similar constraints on how UI elements are handled, resulting in a bunch of infrastructure to allow things to be spun off for later processing on the main thread. > · WebView’s destructor calls DestroyWindow() on a tool tip window > which may or may not have been destroyed (at least on WinCE). When embedding > in a .NET application, there can be a decent gap between the time the > WebView’s window is destroyed and the destructor is called. It’s possible > that in the instances when Windows destroyed the tool tip window (because it > is a child of the webview window) that the tool tip handle is assigned to > another window by the time WebView’s destructor is called. You can guess > what happens then when WebView’s destructor deletes the tool tip window. > Windows in the system disappear – sometimes causing a crash. The only fix I > could figure out what to check to see if the window is still a tool tip > window before deleting it. This sounds like a bug. Could you please file one and add me to the CC list on it? > I don’t know if anyone wants to see a patch land for either of these > problems, they’re confined to embedded WebKit on Windows under .NET… I’d love to see the patches. You are obviously not the only person to suffer from these issues, and it would be great to at least document the issue and how to work around it. Thanks! -Brent
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
