After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729288 - Return values from default signal handlers should not be ignored
Return values from default signal handlers should not be ignored
Status: RESOLVED FIXED
Product: gjs
Classification: Bindings
Component: general
1.40.x
Other All
: Normal normal
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks:
 
 
Reported: 2014-04-30 20:07 UTC by Philip Chimento
Modified: 2015-10-27 22:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch with testcase and fix (2.24 KB, patch)
2014-04-30 20:08 UTC, Philip Chimento
committed Details | Review

Description Philip Chimento 2014-04-30 20:07:20 UTC
There's a missing "return" in the GObject override which means that the return value of a class's default signal handler is ignored. This makes a signal with FIRST_WINS accumulation pretty useless.

See the testcase in the attached patch for an example of what I mean.
Comment 1 Philip Chimento 2014-04-30 20:08:58 UTC
Created attachment 275507 [details] [review]
Patch with testcase and fix
Comment 2 Giovanni Campagna 2014-05-05 14:43:46 UTC
Review of attachment 275507 [details] [review]:

The fix is correct, but really, the on_* syntax was a mistake.
One should use connect() or the vfunc, because on_* does not have a way to chain up and has weird behavior with custom marshallers (which breaks GtkListStore at least)

Anyway, I guess that for compatibility we ought to have it working.
Comment 3 Jasper St. Pierre (not reading bugmail) 2014-05-05 15:36:34 UTC
I don't know any users of on_, so I think we should just remove it.
Comment 4 Philip Chimento 2014-05-05 16:20:17 UTC
Except one who filed this bug :-P

Is there guaranteed to be a vfunc for every signal? I thought that was optional.
Comment 5 Jasper St. Pierre (not reading bugmail) 2014-05-05 16:23:20 UTC
No. Just use this.connect('foo', ...);
Comment 6 Philip Chimento 2014-05-05 22:07:11 UTC
That basically makes signals with accumulators unusable in GJS, as well as RUN_LAST and RUN_CLEANUP. Handlers connected with g_signal_connect() are executed in the order they are connected in (according to GObject docs), so connecting one with this.connect() in an object's constructor will mean that it is run _before_ any signals that an object's API consumers connect.

So for example the FIRST_WINS accumulator that I mentioned in the original bug report would not be able to have a default value, because any signal handler providing that default value would execute before any user-connected handlers.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-05-05 22:33:20 UTC
You could use this.connect_after. They're run in connect();, class_closure, connect_after(); order.
Comment 8 Philip Chimento 2014-05-05 22:59:29 UTC
According to the docs the order is:

1. class closure for RUN_FIRST signals
2. connect()
3. class closure for RUN_LAST signals
4. connect_after()
5. class closure for RUN_CLEANUP signals

No matter what, without default handlers, you lose some versatility with signals in GJS. You can imitate a RUN_FIRST class closure by connect()ing in the object's constructor, and you can imitate a RUN_LAST class closure by connect_after()ing in the constructor, but you lose RUN_CLEANUP.
Comment 9 Cosimo Cecchi 2015-10-27 22:56:59 UTC
Pushed to master