Bug 16307 – [GTK] navigation-requested signal is not stopped

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Salvatore De Paolis]

navigation-requested signal is not stopped  if any handler returns a reply different from WEBKIT_NAVIGATION_RESPONSE_ACCEPT.

[Luca Bruno]

So? In my hopinion it's right. If a callback wants the requested to be ignored, is not a good reason to stop signals. Instead, the IGNORE is relative to the web reqest, while stopping the signal is relative to avoid other callbacks from accepting the request.

What's wrong in that?

[Salvatore De Paolis]

(In reply to comment #1)
> So? In my hopinion it's right. If a callback wants the requested to be ignored,
> is not a good reason to stop signals. Instead, the IGNORE is relative to the
> web reqest, while stopping the signal is relative to avoid other callbacks from
> accepting the request.
> 
> What's wrong in that?
> 

Hi Bruno,
yes this could be also handled by the callback and it works good but navigation-requested now doesn't raise on image loading.

[Michael Natterer]

Re #1: The problem is that without stopping the signal, *all* requests will
always be accepted, because there can be only one return value from a
signal emission, and that's the return value of the last handler which
is the default handler. The g-ish way to solve this is to have a signal
accumulator that automatically stops the emission on certain return
values, just as GtkWidget's event signals stop when one callback returns
TRUE.

[Christian Dywan]

This was fixed in bug 16654.