Opened 15 years ago
Closed 13 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: |
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 (6)
Changed 15 years ago by
Attachment: | event_trigger_prop.txt added |
---|
comment:1 Changed 15 years ago by
Cc: | DanSwitzer2 flesler added |
---|---|
need: | Review → Test Case |
Can you provide a test case where this feature is clearly necessary ?
comment:2 Changed 15 years ago by
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 15 years ago by
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 13 years ago by
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!
comment:5 Changed 13 years ago by
Status: | pending → closed |
---|
Automatically closed due to 14 days of inactivity.
Event Triggered Property