Bug 16654 – [GTK] Signal "navigation-requested" does not react correctly on return TRUE from callbacks

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Lars Strojny]

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.

[Xan Lopez]

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.

[Xan Lopez]

Obviously can't be boolean, since that's not the return type. Maybe our own ad-hoc acc?

[Xan Lopez]

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(-)

[Alp Toker]

Couldn't we just use a boolean accumulator if we defined WEBKIT_NAVIGATION_RESPONSE_ACCEPT as 0? Seems like a sensible default value.

[Xan Lopez]

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.

[Alp Toker]

Comment on attachment 18193 [details]
WebKitNavigationResponse accumulator.

Fair enough.

r=me

[Alp Toker]

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!)