Bug Tracker

Opened 12 years ago

Closed 10 years ago

#3401 closed enhancement

Event property for tracking with an event was fired via actual browser event or via trigger()

Reported by: DanSwitzer2 Owned by: brandon
Priority: major Milestone: 1.3
Component: event Version: 1.2.6
Keywords: Cc: DanSwitzer2, flesler
Blocked by: Blocking:


There should be a way to determine whether an bound event was triggered via an actual browser event or programmatically via the trigger/triggerHandler() events.

There are occasions when you may need to handle code differently based on how the event was fired.

I'm adding this ticket per request of John Resig.

I'm attaching a patch which will add a "triggered" property to the event object. This is "true" when the event was triggered programatically and "false" when the browser fired the event via a user action.

Attachments (1)

event_trigger_prop.txt (827 bytes) - added by DanSwitzer2 12 years ago.
Event Triggered Property

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by DanSwitzer2

Attachment: event_trigger_prop.txt added

Event Triggered Property

comment:1 Changed 12 years ago by flesler

Cc: DanSwitzer2 flesler added
need: ReviewTest Case

Can you provide a test case where this feature is clearly necessary ?

comment:2 Changed 12 years ago by DanSwitzer2

Where I've been running into the problem is when I'm using a lot of event delegation in combination with exposing methods to programmatically call certain functions.

For example, I use a combination of document.click a element.keypress which handles hiding a menu element. In this case I can't use the blur() event to hide the menu, because it interferes with selects of items in the menu. However, if I call the blur() event using the trigger() method I do want it to hide the menu. In this case I need to know whether the event was triggered programmatically or whether it was triggered by the a browser event.

This is just one use case, but there have been other times I wished I could determine the difference. There are other use cases where handling of an event you may want to handle differently based on how it was triggered.

comment:3 Changed 12 years ago by DanSwitzer2

Also, while I think it would be more intuitive to expose the "triggered" event property so that it returns true/false depending on how it was fired, as long as you can tell when a "fake" event object is being used, that's good enough for me.

So even if triggered only existing in a fake event object, that would probably be enough (and wouldn't add much at all to the code base.)

Right now I've been using:

function isJQueryEvent(e){

return !("bubbles" in e
"cancelBubble" in e);


But who knows if those if browsers will continue to pass those properties in all real event objects. I'd much prefer for jQuery to explicitly tell me the event object is fake.

comment:4 Changed 10 years ago by snover

Status: newpending

This ticket has been marked as missing a test case. In an effort to reduce the number of outstanding tickets in the bug tracker, it will be closed automatically in 30 days. In order to prevent this from happening, please provide a working test case. If a test case has already been provided and our records are wrong, please respond to the ticket so that it can be fixed. Thank you!

comment:5 Changed 10 years ago by trac-o-bot

Status: pendingclosed

Automatically closed due to 14 days of inactivity.

Note: See TracTickets for help on using tickets.