[Webkit-unassigned] [Bug 32028] New: WebKitGTK generally does not handle WebView being destroyed in a callback

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32028

           Summary: WebKitGTK generally does not handle WebView being
                    destroyed in a callback
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Critical
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: grant_gayed at ca.ibm.com


using WebKitGTK 1.1.16

Steps to reproduce:

- start with the GtkLauncher example
- add: static int counter = 0;
- add to link_hover_cb:
    if (++counter == 3) {
        fprintf(stdout, "destroy it!!\n"); fflush(stdout);
    gtk_widget_destroy(GTK_WIDGET(web_view));
    }
- run it, hover over a couple of links in the initial page, crash

I assume this is happening because WebKitGTK does not check for whether a
WebView has been destroyed after sending a signal.  I've confirmed similar
problems when destroying a WebView within a callback in at least the following
set:

- "create-web-view" crashes
- "hovering-over-link" crashes
- "load-finished" writes: GLib-CRITICAL **: g_hash_table_lookup_extended:
assertion `hash_table != NULL' failed
- "notify::progress" crashes
- "notify::title" writes:
     (GtkLauncher:18119): GLib-GObject-WARNING **: instance with invalid (NULL)
class pointer
     (GtkLauncher:18119): GLib-GObject-CRITICAL **: g_signal_emit_by_name:
assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
- "populate-popup" crashes
- "status-bar-text-changed" crashes

Destroying a widget in a callback is a valid thing to do.  SWT (Eclipse) is
keen to make use of WebKitGTK in its Browser widget, but we cannot do so if
Browser client callbacks will crash in scenarios like this.  This is why the
severity is marked as critical, even though in some other embedding contexts a
simple "well, don't do that" might be a valid workaround ;-).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.