Bug Tracker

Opened 11 years ago

Closed 8 years ago

Last modified 8 years ago

#3368 closed enhancement (fixed)

event.metaKey should be assigned to event.ctrlKey on Non-Mac only

Reported by: tzury Owned by: dmethvin
Priority: low Milestone: 1.7
Component: event Version: 1.4.4
Keywords: needsreview, 1.7-discuss Cc:
Blocked by: Blocking:

Description (last modified by ajpiano)

at jquery.js | version 1.2.6 | line 2150


Add metaKey to non-Mac browsers (use ctrl for PC's and Meta for Macs)

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

event.metaKey = event.ctrlKey;

This is causing a buggy behavior in the following scenario: A user wish to bind ctrl+x to function-A and command+x to function-B When ctrl+x were pressed, event.metaKey is true as well as event.ctrlKey so function-B is called even though only function-A should be triggered.

The the would obviously be to add additional check for Mac or non Mac operating system, something like:

if ( !event.metaKey && event.ctrlKey && !(/Mac OS/.test(navigator.userAgent))

event.metaKey = event.ctrlKey;

Change History (24)

comment:1 Changed 11 years ago by flesler

Owner: changed from brandon to flesler
Status: newassigned

comment:2 Changed 10 years ago by yehuda

Resolution: invalid
Status: assignedclosed

The purpose of event.metaKey is to provide a way of binding functionality to "user's native meta key" + "other key". For instance, meta+b could be used to trigger a "bold" mode. On OSX, this would be command+b, but on Windows, it would be ctrl-b.

comment:3 Changed 10 years ago by babyman

Resolution: invalid
Status: closedreopened

Leaving all philosophy aside the Apple keyboard has a command (meta) key AND a control key. It is possible on a Mac to press the Control key WITHOUT pressing the Command key.

Therefore on a Mac meta != control it is simply not true regardless "the purpose of event.meta".

Even the author of the code indicated in their comment that this was intended for PC's only, they simple forgot to filter out Macs:


comment:4 Changed 10 years ago by babyman

This seems like it might be a pretty decent workaround for those that are experiencing this issue, instead of:

var cmd = event.metaKey;


var cmd = event.originalEvent.metaKey ? event.originalEvent.metaKey : false;

This means that cmd will be true only when the original event metaKey value was true, in all other cases it will be false even if the control key has been pressed (which seems like reasonable behaviour).

I'm new at this so feedback welcome ;)

comment:5 Changed 9 years ago by snover

Keywords: needsreview added
Milestone: 1.3
Priority: majorlow
Status: reopenedopen

I think it would make sense to create a separate cmdKey property so people can use metaKey as an “either ctrl or cmd depending upon platform” key, and still retrieve the value of the command key explicitly if they need to.

comment:6 Changed 9 years ago by jquery@…

Well this three year old bug is a mess. Clearly it should be possible to tell the difference between a control and meta key, since the browser can trap any key it wants.

Hopefully the original event is unadulterated at this point so we can do the right thing.

comment:7 Changed 9 years ago by dmethvin

Yes, event.originalEvent is there if you would like to read its tea leaves in a different way. I like snover's idea of a separate cmdKey property but given that there is a lot of code out there using the current properties I don't know if it would make things better or worse.

comment:8 Changed 9 years ago by timmywil

So meta key here refers to the command key? The meta key as I understand it can be changed to alt/option on a Mac and then there is the start button key on pc keyboards. So I guess my question is can we guarantee consistency?

comment:9 Changed 8 years ago by john

Milestone: 1.next
Type: bugenhancement

I'm going to make this an enhancement and we can look at adding a new cmdKey in 1.7 (while removing the metaKey hack).

comment:10 Changed 8 years ago by john

Keywords: 1.7-discuss added

Nominating ticket for 1.7 discussion.

comment:11 Changed 8 years ago by dmethvin

+0, I do not know enough to swing on this, but don't think existing code should be broken by a solution.

comment:12 Changed 8 years ago by Rick Waldron

Description: modified (diff)


comment:13 Changed 8 years ago by jaubourg

+0, Seems booby trapped to me

comment:14 Changed 8 years ago by ajpiano

+1, I like the adding of a cmdKey - let people actually test for what they're trying to test for.

comment:15 Changed 8 years ago by timmywil

+0, metaKey works correctly as a proper indicator of pressing command (and it is still possible to differentiate between control and meta). This may be more a problem with the ctrlKey logic. http://jsfiddle.net/timmywil/wWrAR/

comment:16 Changed 8 years ago by addyosmani

Description: modified (diff)


comment:17 Changed 8 years ago by danheberden

Description: modified (diff)


comment:18 Changed 8 years ago by john


comment:19 Changed 8 years ago by scottgonzalez


comment:20 Changed 8 years ago by addyosmani


comment:21 Changed 8 years ago by jzaefferer


comment:22 Changed 8 years ago by ajpiano

Description: modified (diff)
Milestone: 1.next1.7

comment:23 Changed 8 years ago by dmethvin

Owner: changed from flesler to dmethvin
Status: openassigned

Let's see if we can get this closed for 1.7.

On Mac, this code should never be executed I assume; I don't have a Mac to test on. So let's move on to Windows.

On Firefox 6, Chrome 13, Opera 11.5, and IE9, metaKey and ctrlKey move in unison and both are Boolean, so the code isn't needed.

On IE6, IE7 and IE8, metaKey is undefined when the Ctrl key is pressed alone but true when pressed in unison with another key. I suspect this may be why the patch was put in originally. So if we check for typeof(e.metaKey==="undefined") rather than falsey it should handle this case.

comment:24 Changed 8 years ago by dmethvin

Resolution: fixed
Status: assignedclosed

Fixed along with #8789 refactor.

Note: See TracTickets for help on using tickets.