Help understanding an event object


#1

I working on someone else’s code that looks like this. It is meant to trap events sent by using the jQuery call trigger, usually from the Atom app. So these are actually “commands”.

trigger = $.fn.trigger
@originalTrigger = trigger
$.fn.trigger = (e) ->
  addEventToLog e
  trigger.apply(this, arguments)

It seems to me that it is trapping normal jQuery events. When I look at one of these events in the console I see this …

jQuery.Event  (as seen in console)
  isTrigger: 3
  jQuery 20309074876944068819: true
  namespace: "bs.tooltip"
  namespace_re: /(^|\.)bs\.(?:.*\.|)tooltip(\.|$)/
  result: undefined
  target: li.tab.sortable.active
  timeStamp: 1414891875233
  type: "hide"

This is all and good. I need the target property and it’s right there.

However, in my code I get a value of undefined for event.target. I got totally confused and so I stole a routine from mdn.com called

getOwnAndPrototypeEnumerablesAndNonenumerables

which as you can see claims to show absolutely every property on an object. When I ran this on that same event object I got …

Array[24]
  0: "type"
  1: "timeStamp"
  2: "jQuery20309074876944068819"
  3: "isDefaultPrevented"
  4: "isPropagationStopped"
  5: "isImmediatePropagationStopped"
  6: "preventDefault"
  7: "stopPropagation"
  8: "stopImmediatePropagation"
  9: "abortKeyBinding"
  10: "currentTargetView"
  11: "targetView"
  12: "constructor"
  13: "toString"
  14: "toLocaleString"
  15: "valueOf"
  16: "hasOwnProperty"
  17: "isPrototypeOf"
  18: "propertyIsEnumerable"
  19: "__defineGetter__"
  20: "__lookupGetter__"
  21: "__defineSetter__"
  22: "__lookupSetter__"
  23: "__proto__"

This has only two properties in common with what the console says is in the same object. And the target I need isn’t there.

Is this some kind of HTML5 magic being used by Atom? I certainly don’t remember seeing the console show the wrong thing in all my web dev days.

I’ll look in core for the code that calls trigger but I thought I should bring this up here since it could confuse any package dev.


#2

Well, there were no jQuery.fn.trigger calls in all of core. So they must come from atom-shell. Is it possible atom-shell is doing something weird in the event system?


#3

atom-shell doesn’t use jQuery, that’s entirely Atom.


#4

Then where the heck are the trigger calls? There must be some other call that jQuery turns into a trigger. I saw two trigger calls in core and they were in benchmark. I see where the $.fn.trigger function is overridden to catch commands, I just don’t see where the commands are sent.

Maybe jQuery sends native events to trigger internally? I guess I’ll have to read jQuery now.