[webkit-gtk] Signals with default handlers

Gavin Lambert gavinl at compacsort.com
Tue May 31 18:28:47 PDT 2011


I've been writing a program which uses webkitmm (and incidentally, if anyone
is interested, I have some local updates to webkitmm to bring it up to
support WebKit 1.4.0 -- though I haven't mm-encapsulated the JS/DOM/libsoup
types).


I'm getting some undesirable behaviour from a signal which has a default
handler (virtual method defined in the underlying GTK+ class) --
specifically, it appears to be ignoring attempts to connect a signal
handler, and invoking the original GTK+ handler instead of my own.  Some
relevant bits of code:

webkitmm source definition:
  _WRAP_SIGNAL(bool console_message(const std::string& message, guint line,
const std::string& source_id), "console-message")

Webkit/GTK signal definition:
    webkit_web_view_signals[CONSOLE_MESSAGE] =
g_signal_new("console-message",
            G_TYPE_FROM_CLASS(webViewClass),
            (GSignalFlags)G_SIGNAL_RUN_LAST,
            G_STRUCT_OFFSET(WebKitWebViewClass, console_message),
            g_signal_accumulator_true_handled,
            NULL,
            webkit_marshal_BOOLEAN__STRING_INT_STRING,
            G_TYPE_BOOLEAN, 3,
            G_TYPE_STRING, G_TYPE_INT, G_TYPE_STRING);

My attempt to attach signal handler:
  m_web_view.signal_console_message().connect(sigc::mem_fun(this,
&MyWindow::on_console_message));

My handler is never called; the default handler defined inside WebKit/GTK is
called instead.

If I instead derive a subclass from WebView and override the virtual
on_console_message function in that, then it gets called as expected.  (And
if that calls the base class implementation, then it does both, as
expected.)

So: why aren't "traditional" signal handlers getting called for this signal?
Is this a bug or have I set something up incorrectly?

(Incidentally, signals wrapped using no_default_handler seem to correctly
call their connected signal handler.)




More information about the webkit-gtk mailing list