Side navigation
#10666 closed bug (invalid)
Opened November 04, 2011 12:59PM UTC
Closed November 14, 2011 09:04PM UTC
event.metaKey returns false when ctrl key is down
| Reported by: | slevin.kil@gmail.com | 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.
Attachments (0)
Change History (5)
Changed November 04, 2011 01:05PM UTC by comment:1
Changed November 05, 2011 09:30PM UTC by comment:2
| component: | unfiled → event |
|---|---|
| milestone: | None → 1.next |
| priority: | undecided → low |
| status: | new → open |
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.
Changed November 05, 2011 09:49PM UTC by comment:3
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.
Changed November 14, 2011 05:35PM UTC by comment:4
| milestone: | 1.next → 1.7.1 |
|---|---|
| owner: | → dmethvin |
| priority: | low → high |
| status: | open → assigned |
Changed November 14, 2011 09:04PM UTC by comment:5
| cc: | → scott.gonzalez |
|---|---|
| resolution: | → invalid |
| status: | assigned → closed |
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
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.