Bug 29890 (lxp149) - [GTK] page transition may crash webkit
Summary: [GTK] page transition may crash webkit
Status: RESOLVED FIXED
Alias: lxp149
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 30125 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-29 11:47 PDT by luying.pan
Modified: 2009-10-19 04:33 PDT (History)
5 users (show)

See Also:


Attachments
bug report (17.51 KB, text/plain)
2009-09-30 10:09 PDT, luying.pan
no flags Details
proposed fix (3.18 KB, patch)
2009-10-09 13:15 PDT, Gustavo Noronha (kov)
xan.lopez: review+
gns: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description luying.pan 2009-09-29 11:47:21 PDT
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.
Comment 1 luying.pan 2009-09-30 10:09:19 PDT
Created attachment 40380 [details]
bug report
Comment 2 Xan Lopez 2009-10-06 23:32:56 PDT
---- 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.
Comment 3 Gustavo Noronha (kov) 2009-10-09 13:07:56 PDT
Same thing that is making fast/loader/unload-hyperlink-targeted.html crash. Patch incoming.
Comment 4 Gustavo Noronha (kov) 2009-10-09 13:15:31 PDT
Created attachment 40962 [details]
proposed fix
Comment 5 Xan Lopez 2009-10-09 13:27:54 PDT
(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?
Comment 6 Gustavo Noronha (kov) 2009-10-09 14:17:16 PDT
(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 7 Xan Lopez 2009-10-15 06:59:59 PDT
Comment on attachment 40962 [details]
proposed fix

OK, r=me
Comment 8 Gustavo Noronha (kov) 2009-10-15 08:02:38 PDT
Landed as r49627.
Comment 9 Gustavo Noronha (kov) 2009-10-19 04:33:35 PDT
*** Bug 30125 has been marked as a duplicate of this bug. ***