Signal "navigation-requested" is supposed to stop emitting the signal (and therefore the default handler should not be called). This is currently not the case. A working workround is to call g_signal_stop_emission_by_name() on the webview object.
What he means is that there's no way to prevent the default handler from running and returning its value unless you stop the signal manually or connect with g_signal_connect_after (making your value 'win'). I think the signal should have a boolean accumulator.
Obviously can't be boolean, since that's not the return type. Maybe our own ad-hoc acc?
Created attachment 18193 [details] WebKitNavigationResponse accumulator. * WebView/webkitwebview.cpp: use our own accumulator for signals returning WebKitNavigationResponse. The emission will be stopped when any callback returns anything but WEBKIT_NAVIGATION_RESPONSE_ACCEPT. --- WebKit/gtk/ChangeLog | 13 +++++++++++++ WebKit/gtk/WebView/webkitwebview.cpp | 20 +++++++++++++++++++- 2 files changed, 32 insertions(+), 1 deletions(-)
Couldn't we just use a boolean accumulator if we defined WEBKIT_NAVIGATION_RESPONSE_ACCEPT as 0? Seems like a sensible default value.
Not sure if it would freak out because of the difference in types (I can check), but that would be a hack no matter how you look at it. I think our own accumulator is the right thing to do.
Comment on attachment 18193 [details] WebKitNavigationResponse accumulator. Fair enough. r=me
Landed in r29147 with several whitespace and formatting fixes. (I guess it was this way to match the formatting patch which wasn't accepted, so will fix up before landing, but more careful next time please!)