Bug Tracker

Opened 7 years ago

Closed 7 years ago

#10666 closed bug (invalid)

event.metaKey returns false when ctrl key is down

Reported by: slevin.kil@… Owned by: dmethvin
Priority: high Milestone: 1.7.1
Component: event Version: 1.7
Keywords: Cc: scottgonzalez
Blocked by: Blocking:

Description

So, we have an "event.metaKey" that can be either true or false and is here to represent either Ctrl key on WIndows/Linux or Command key on Mac OS X.

Prior to jQuery 1.7

event.metaKey was assigned based on this code:

if ( !event.metaKey && event.ctrlKey ) {

event.metaKey = event.ctrlKey;

}

Which basically says that if metaKey is false and ctrlKey is true, then we assign ctrlKey to metaKey which makes it true.

But now, in jQuery 1.7 code's been changed to the following:

if ( event.metaKey === undefined ) {

event.metaKey = event.ctrlKey;

}

And that code means that if we metaKey is undefined, then and only then we assign ctrlKey to metaKey.

Now to the bug. At this point it's been noticed only in jQuery UI selectable plugin.

If you use that plugin, you can hold down ctrl/command key to select multilpe elements on the page. Problem is, that plugin in it's code uses following condition check to find, if Ctrl key is dow:

if (event.metaKey) .. hurr durr..

You see, that code will work on Mac OS X because on that OS metaKey is commandKey and therefore it gets correct value.

On Windows or Linux there's no command key and therefore it is stick with "false" value indefinitely which in it's turn breaks functionality that relies on event.metaKey check. And that's exactly what's happening with jQuery sortable.

Change History (5)

comment:1 Changed 7 years ago by slevin.kil@…

jsfiddle demo:

Older jquery: http://jsfiddle.net/hVFJ2/

jQuery 1.7: http://jsfiddle.net/U7cnL/

In both cases you can hold Ctrl key (Windows/*nix OS) and multiselect doesn't wok.

comment:2 Changed 7 years ago by timmywil

Component: unfiledevent
Milestone: None1.next
Priority: undecidedlow
Status: newopen

Dave and I discussed this and there's not really a way to get the desired behavior for everyone without checking the platform. We fell on either leaving it the way it is (which means event.metaKey won't be right in IE9 but users still have event.ctrlKey which is the same there) or reverting to the old way, which means event.metaKey will not be reliable on a MAC. Dave and I seem to land on different sides.

comment:3 Changed 7 years ago by slevin.kil@…

Well, i personally would agree with some of the guys that commented on the old ticket about metaKey (http://bugs.jquery.com/ticket/3368) and i find that user yehuda (http://bugs.jquery.com/ticket/3368#comment:2) and snover ((http://bugs.jquery.com/ticket/3368#comment:5)) described desirable behavior of metaKey pretty well.

AS far as i understood, metaKey is a key

Anyway, thanks and i hope decision that would be done on that matter would satisfy all parties.

comment:4 Changed 7 years ago by dmethvin

Milestone: 1.next1.7.1
Owner: set to dmethvin
Priority: lowhigh
Status: openassigned

comment:5 Changed 7 years ago by dmethvin

Cc: scott.gonzalez added
Resolution: invalid
Status: assignedclosed

I talked to scott.gonzalez and we're going to leave 1.7 as is; UI will patch to check for both meta and ctrl since they are separate keys on some platforms.

The discussion in #3368 was the original justification for splitting the two apart in 1.7. Defining a new non-W3C key property at this point won't really help. The spec doesn't provide much guidance about what to do, but it seems like what we were doing before was probably not ideal. Spec included here for reference:

http://www.w3.org/TR/DOM-Level-3-Events/#events-KeyboardEvent-metaKey

Note: See TracTickets for help on using tickets.