I've tried this from both epiphany and seed. I'm trying to extend a webkit-based browser to do some automatic browsing. A simple scenario would be to wait for the current page to finish loading and then browse to some other page. So I added a signal handler for WebKitWebView's load-finished signal inside which webkit_web_view_load_uri is called. However this crashes webkit. See attachment for more details.
Created attachment 40380 [details] bug report
---- Critical and fatal warnings logged during execution ---- ** epiphany **: WebKitWebResource* webkit_web_view_get_resource(WebKitWebView*, char*): assertion `resourceFound || g_str_equal(identifier, priv->mainResourceIdentifier)' failed ** epiphany **: const gchar* webkit_web_resource_get_uri(WebKitWebResource*): assertion `WEBKIT_IS_WEB_RESOURCE(webResource)' failed CCing Gustavo because of these warnings.
Same thing that is making fast/loader/unload-hyperlink-targeted.html crash. Patch incoming.
Created attachment 40962 [details] proposed fix
(In reply to comment #4) > Created an attachment (id=40962) [details] > proposed fix You seem to give different reasons for this patch in the commit message and in the comments? Can this only happen when a load is cancelled or are there situations where a resource can be requested when a new load has already started? Is it really OK to clean all resources in the place we do it?
(In reply to comment #5) > (In reply to comment #4) > > Created an attachment (id=40962) [details] [details] > > proposed fix > > You seem to give different reasons for this patch in the commit message and in > the comments? Can this only happen when a load is cancelled or are there > situations where a resource can be requested when a new load has already > started? Is it really OK to clean all resources in the place we do it? The reason is the same, I just explained different aspects of it, maybe I can rephrase one of them to make it better? Suggestions? So what happens is that another provisional load has already been started, but one or more resource loads didn't hit didFinishLoading yet. This doesn't happen if you simple cancel a load, because the hash table is not cleared by cancelling. This seems to happen mainly when the transition is caused by an unload handler or inside the load-finished handler. I think we're clearing the hash table at the correct spot - when the provisional load starts.
Comment on attachment 40962 [details] proposed fix OK, r=me
Landed as r49627.
*** Bug 30125 has been marked as a duplicate of this bug. ***