Bug #1929


JSlot still incurs call to server when connected to JSignal

Added by Alice Margatroid over 10 years ago. Updated about 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


To my understanding and reading of the documentation, a JSignal represents a signal, fired from JavaScript, ordinarily making a leap to C, but with a special provision for JSlot's to stay within javascript.

This is, in fact, explicitly stated in the documentation: JSlot's do not cause the event to be propogated to the application.

This does not seem to be the case, either in my small test case, or in my (admittedly cursory) reading of the JSlot and EventSignal code. There appears to be no provisions for detecting if all slots are JSlots, which would allow the entire call to application to be filtered out. Instead, it appears JSlot is treated identically to a StatelessSlot, which causes both a javascript function AND the C slot to be called: certainly beneficial for a stateless slot implimentation (which I assume is the most common situation), but not so much for code which ought to stay in the client.

My test case involves WMediaPlayer and the JSignal it emits timeUpdated, which is called quite frequently (thus why I wished to push it entirely into javascript, but keep it managable and encapsulated with a JSlot). You should get the broad strokes of it at a glance, but it creates a basically blank JSlot, connects it to the JSignal of timeUpdated, and connects the MediaPlayer to a streaming radio source (feel free to connect to it to run the test, it's just a loop):

What happens should be easily apparent from console: as soon as a client connects, they constantly send requests back to the server, which show up in the access log as a WebRequest. If you use an in-browser javascript inspector, you can clearly see why this is: $('#ohmhn2d .jp-jplayer').bind('jPlayer_timeupdate.Wt', function(o, e) { Wt.sf0(o,e);Wt.emit('ohmhn2d','jPlayer_timeupdate.Wt');});

The JSlot is executed, and then a full call back to the application occurs!

What I am sure is happening is that there is no optimization for a slot chain being all JSlots, and that this important optimization was either overlooked or simply isn't engaging correctly (if I missed it in the code). As a work around, I can use doJavaScript() to establish my own hook, but this is clearly a hack around a small but vital issue.

Actions #1

Updated by Koen Deforche over 10 years ago

  • Status changed from New to Resolved
  • Assignee set to Koen Deforche
  • Target version set to 3.3.1


This is indeed not the expected behavior, and I've fixed this in my git copy. It'll be available in the repo shortly.



Actions #2

Updated by Koen Deforche about 10 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF