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.

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:

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

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

var cmd = event.metaKey;

use:

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 ;)

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.

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.

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.

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?

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).

Nominating ticket for 1.7 discussion.

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

+1,

+0, Seems booby trapped to me

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

+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/

+1,

+1

+1

+1

+1

+1

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.

Fixed along with #8789 refactor.