Side navigation
#3401 closed enhancement ()
Opened September 23, 2008 03:18PM UTC
Closed November 11, 2010 11:09PM UTC
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: |
Description
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)
Change History (5)
Changed September 23, 2008 10:51PM UTC by comment:1
cc: | → DanSwitzer2, flesler |
---|---|
need: | Review → Test Case |
Changed September 24, 2008 03:14PM UTC by comment:2
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.
Changed September 24, 2008 03:22PM UTC by comment:3
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.
Changed October 14, 2010 03:14AM UTC by comment:4
status: | new → pending |
---|
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!
Changed November 11, 2010 11:09PM UTC by comment:5
status: | pending → closed |
---|
Automatically closed due to 14 days of inactivity.
Can you provide a test case where this feature is clearly necessary ?