Skip to main content

Bug Tracker

Side navigation

#14725 closed bug (notabug)

Opened January 24, 2014 02:47AM UTC

Closed March 10, 2014 02:08PM UTC

Event.data is proposed to be used for input events

Reported by: d.wachss@prodigy.net Owned by: dmethvin
Priority: low Milestone: 1.11.1/2.1.1
Component: event Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:
Description

In the DOM3 event specification (http://www.w3.org/TR/DOM-Level-3-Events/#events-inputevents),

beforeinput
and
input
events have a
data
attribute.
jQuery.event.fix
sets the
data
attribute to whatever is passed in the
on()
handler.

While the

data
attribute is not yet implemented in any browsers, this is going to break when it happens. I have a text-input library and am trying to implement the
input
event correctly, but this breaks that.

Changing the jQuery

data
is likely impossible, but jQuery is used on more than half of all websites. Surely the jQuery foundation has some pull to change a future spec.

Otherwise, using a guard like

if (event.originalEvent && handleObj.data === undefined){
  event.data = event.originalEvent.data;
}else{
  event.data = handleObj.data;

may help (with documentation that data passed in

on()
will overwrite the native
data
)

Attachments (0)
Change History (8)

Changed January 24, 2014 02:49AM UTC by dmethvin comment:1

status: newopen

There is already at least one existing event that passes an event.data I am pretty sure. This would be a good idea though.

Changed March 01, 2014 10:35PM UTC by dmethvin comment:2

component: unfiledevent
milestone: None1.12/2.2
owner: → dmethvin
priority: undecidedlow
status: openassigned

Changed March 04, 2014 02:53PM UTC by dmethvin comment:3

milestone: 1.12/2.21.11.1/2.1.1

Changed March 06, 2014 04:23AM UTC by dmethvin comment:4

I've looked at this some more and think it's not the right direction.

We normalize a small subset of properties into the main event object passed to the handler. Right now the jQuery data is available consistently on event.data and the native data is always on event.originalEvent.data. This would make it more of a crapshoot as to what event.data represented which seems like a bad idea and even more confusing.

It's unfortunate that the standards group picked the same name as our existing property but there isn't much we can do about it now.

Changed March 06, 2014 09:45PM UTC by d.wachss@prodigy.net comment:5

I understand, though this fact should be documented.

As I mentioned, the best solution is political: the proposed standard should be changed to not break jQuery, especially since it has not been implemented yet. Does the jQuery foundation have any input in the W3C? You have a greater market share (and mind share) than any individual browser.

Changed March 06, 2014 09:54PM UTC by dmethvin comment:6

That ship sailed long ago, the input event has been around for years but just not widely implemented. Really this is just like any other value that jQuery doesn't normalize, the best place to get it is event.originalEvent.

It's already documented:

https://api.jquery.com/category/events/event-object/

Changed March 07, 2014 01:43AM UTC by d.wachss@prodigy.net comment:7

Good enough.

The documentation on the Event object[https://api.jquery.com/category/events/event-object/] actually explicitly says that the data field is copied (look under "Event Properties").

When I noted this, it took me an hour of digging through the source to figure out why it wasn't working, and even

$.event.fixHooks['input'] = { props:['data'] };

wouldn't work. That fact (that the data field is set ''after'' the event is normalized) ought to be explicitly noted in Event.data[https://api.jquery.com/event.data/].

Changed March 10, 2014 02:08PM UTC by dmethvin comment:8

resolution: → notabug
status: assignedclosed