Bug Tracker

Modify

Ticket #9101 (closed bug: patchwelcome)

Opened 3 years ago

Last modified 3 years ago

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:
Blocking: Blocked by:

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/

Change History

comment:1 Changed 3 years ago by rwaldron

  • Owner set to rwaldron
  • Priority changed from undecided to high
  • Status changed from new to assigned
  • Component changed from unfiled to event

Confirmed

comment:2 Changed 3 years ago by dmethvin

  • Owner changed from rwaldron to gryzzly
  • Status changed from assigned to 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.

comment:3 Changed 3 years ago by gryzzly

  • Status changed from pending to 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.

Version 0, edited 3 years ago by gryzzly (next)

comment:4 Changed 3 years ago by dmethvin

  • Priority changed from high to low
  • Status changed from new to 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.

comment:5 Changed 3 years ago by gryzzly

Sure thing, thanks.

Though calling jQuery.event.fix() directly on this event didn't help either – see  http://jsfiddle.net/gryzzly/5aDv2/5/

comment:6 Changed 3 years ago by addyosmani

  • Status changed from open to closed
  • Resolution set to patchwelcome

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.

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.