Side navigation
#9101 closed bug (patchwelcome)
Opened May 04, 2011 04:00PM UTC
Closed July 12, 2011 05:26PM UTC
An Event object created with $.Event() constructor doesn't match the actual jQuery Event object
| Reported by: | gryzzly | Owned by: | gryzzly |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | event | Version: | 1.6 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Creating an event with $.Event() constructor for keyboard events doesn't normalize event object in a consistent way. I.e. created object doesn't have "which" property - and an event created by actual keypress does.
Tested in Chrome 11.0.696.57, Safari 5.0.4 (6533.20.27), Firefox 4.0.1 and Opera 11.10 b. 2092 on Mac OS X 10.6.7
Example code: http://jsfiddle.net/gryzzly/5aDv2/
Attachments (0)
Change History (6)
Changed May 04, 2011 05:00PM UTC by comment:1
| component: | unfiled → event |
|---|---|
| owner: | → rwaldron |
| priority: | undecided → high |
| status: | new → assigned |
Changed May 04, 2011 06:46PM UTC by comment:2
| owner: | rwaldron → gryzzly |
|---|---|
| status: | assigned → pending |
Well the whole idea is that if you're creating a fake event, you'll do a good job of faking the data you need from the event object. In your example, what exactly should which be? We don't know the button you're trying to fake, there is absolutely no information we can use to determine it.
Changed May 04, 2011 07:07PM UTC by comment:3
| _comment0: | > We don't know the button you're trying to fake, there is absolutely no information we can use to determine it. \ \ $(document).trigger($.Event('keypress', { \ keyCode: 64 \ })) \ \ As far as I know and have used for quite a while, which == keycode when e.keycode isn't available: \ var which = e.keyCode || e.which; // this is the code I've been using for some time \ \ Hence when I create jQuery.Event object I expect it to normalize keyCode to become .which, just as it does for the real events. → 1304536116209783 |
|---|---|
| status: | pending → new |
We don't know the button you're trying to fake, there is absolutely no information we can use to determine it.
$(document).trigger($.Event('keypress', {
keyCode: 64
}))
As far as I know and have used for quite a while, which == keycode when e.keycode isn't available:
var which = e.keyCode || e.which; // this is the code I've been using for some time
Hence when I create jQuery.Event object I expect it to normalize keyCode to become .which, just as it does for the real events.
Changed May 05, 2011 02:30PM UTC by comment:4
| priority: | high → low |
|---|---|
| status: | new → open |
Ah, okay, I see what you're saying. Sorry! We're not calling jQuery.event.fix on those events. But...doing so might have some serious performance implications. We definitely would only want to do this if someone provided the second arg to Event.
For now I'm inclined to leave it as-is, rwaldron and I have been talking about a better way to to jQuery.event.fix that may be in 1.7.
Changed May 05, 2011 03:55PM UTC by comment:5
Sure thing, thanks.
Though calling jQuery.event.fix() directly on this event didn't help either – see http://jsfiddle.net/gryzzly/5aDv2/5/
Changed July 12, 2011 05:26PM UTC by comment:6
| resolution: | → patchwelcome |
|---|---|
| status: | open → closed |
As dmethvin mentions we're likely to keep this as-is for the time being due to performance risks and we haven't yet defined a better way to address this on the 1.7 roadmap during discussions, I'll be closing this ticket as patchwelcome.
Should a member of the team wish to reopen and continue the discussion at a point in the future, please feel free to.
Confirmed