r37922 exposed a bug in ScriptController::clearWindowShell where the call to page->group() initializes the group eventhough we're still in the process of destroying the page and its resources (there shouldn't be a group anymore but group() creates one if there is none). I have attached a fix which just adds the group if we have a groupName. Question is can a valid group be empty? I think clearWindowShell() is confusing since instead of just clearing the window, it just replaces it with a new one - see changeset r32585.
Created attachment 24830 [details] check if we have a group before adding a group profile to the window
Could you create a test case that is showing this issue? E.g. when running the prepare-ChangeLog script one should see the warning in capital letters, we should start to take that warning serious.
Created attachment 24848 [details] test case (In reply to comment #2) > Could you create a test case that is showing this issue? E.g. when running the > prepare-ChangeLog script one should see the warning in capital letters, we > should start to take that warning serious. Sure. Please see attached. Thanks for reminding me =)
Hmm... I don't see it. Do you still get it on a clean rebuild? I open the file in DumpRenderTree and GtkLauncher and have a ToT build.
Created attachment 25412 [details] backtrace
Hi Sam! The patch attached herein is just a workaround. The assertion was triggered due to another gtk bug whereby we are not calling FrameLoader::detachFromParent on WebView destruction (like mac does). Anyway, comment #1 should explain what I think is the issue here. I'm not familiar with that part of WebCore yet so any feedback would be appreciated. Thanks!
Comment on attachment 24830 [details] check if we have a group before adding a group profile to the window If this is a workaround for a GTK-specific bug, then I don't think it should be added unconditionally for all platforms. There's nothing in the patch that explains this. And whether or not this is a workaround for a GTK-specific bug, then I'd like to see the test case included with the bug fix in a single patch. review- for now until this minor business is resolved.
Do we still need that? The ref counting fixes for WebFrame and WebView might/should have fixed it.
(In reply to comment #8) > Do we still need that? The ref counting fixes for WebFrame and WebView > might/should have fixed it. > Zecke, I'm still getting this error even after the webframe/webview leak fix.
I promise I did search for this bug to no avail. Should enhance my bug searching skill, I guess. I reported a related bug, with a different fix here as https://bugs.webkit.org/show_bug.cgi?id=22966.
*** This bug has been marked as a duplicate of 22966 ***