As the title says. This results in ASSERTion failures and random crashed. There's probably a far better solution but the attached diff points out the crashes I noticed so far.
Created attachment 22384 [details] Some naive fixes
Xavier Claessens has had the sames issues last week when he embedded WebKitGtk into Empathy. Raising to Major as this is crashing the embedding apps. To quickly solve is issue, we replaced the ASSERT(containingWindow()) by a "if (containingWindow()) return;". This needs more investigation.
(In reply to comment #2) > Xavier Claessens has had the sames issues last week when he embedded WebKitGtk > into Empathy. > > Raising to Major as this is crashing the embedding apps. > > To quickly solve is issue, we replaced the ASSERT(containingWindow()) by a "if > (containingWindow()) return;". This needs more investigation. As a workaround you can use GtkPlug and GtkSocket. This way the WebView widget always has a toplevel and you can realize it. But this feels so wroooong ;-)
We have encountered places where countainingWindow() isn't null but countainingWindow()->window is. (Opening the archives window in Empathy (with adium themes)).
(In reply to comment #1) > Created an attachment (id=22384) [edit] > Some naive fixes For the fixes for PlatformScreen see bug #16881, I will post an updated patch in the next days. The other one (in the update method) seems ok. Any comment from a reviewer? (In reply to comment #2) > Xavier Claessens has had the sames issues last week when he embedded WebKitGtk > into Empathy. > > Raising to Major as this is crashing the embedding apps. > > To quickly solve is issue, we replaced the ASSERT(containingWindow()) by a "if > (containingWindow()) return;". This needs more investigation. This is a different issue from bug #19370, so not related to empathy. In that case the containingWindow() is null, in this case it's not null but not realized.
I'll resolve this as WONTFIX as the issues addressed by the patch have already been addressed by other (landed) patches. cheers