gecko-dev/dom/webidl/KeyboardEvent.webidl

73 строки
2.5 KiB
Plaintext
Исходник Обычный вид История

/* -*- Mode: IDL; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
* You can obtain one at http://mozilla.org/MPL/2.0/.
*/
[Constructor(DOMString typeArg, optional KeyboardEventInit keyboardEventInitDict)]
interface KeyboardEvent : UIEvent
{
Bug 1479964 - Set KeyboardEvent.keyCode and KeyboardEvent.charCode to same value if the event is "keypress" event r=smaug Chrome sets both KeyboardEvent.keyCode and KeyboardEvent.charCode of "keypress" event to same value. On the other hand, our traditional behavior is, sets one of them to 0. Therefore, we need to set keyCode value to charCode value if the keypress event is caused by a non-function key, i.e., it may be a printable key with specific modifier state and/or different keyboard layout for compatibility with Chrome. Similarly, we need to set charCode value to keyCode value if the keypress event is caused by a function key which is not mapped to producing a character. Note that this hack is for compatibility with Chrome. So, for now, it's enough to change the behavior only for "keypress" event handlers in web content. If we completely change the behavior, we need to fix a lot of default handlers and mochitests too. However, it's really difficult because default handlers check whether keypress events are printable or not with following code: > if (event.charCode && > !event.altKey && !event.ctrlKey && !event.metaKey) { or > if (!event.keyCode && > !event.altKey && !event.ctrlKey && !event.metaKey) { So, until we stop dispatching "keypress" events for non-printable keys, we need complicated check in each of them. And also note that this patch changes the behavior of KeyboardEvent::KeyCode() when spoofing is enabled and the instance is initialized by initKeyEvent() or initKeyboardEvent(). That was changed by bug 1222285 unexpectedly and keeping the behavior makes patched code really ugly. Therefore, this takes back the old behavior even if spoofing is enabled. Differential Revision: https://phabricator.services.mozilla.com/D7974 --HG-- extra : moz-landing-system : lando
2018-10-09 07:43:37 +03:00
[NeedsCallerType]
readonly attribute unsigned long charCode;
[NeedsCallerType]
readonly attribute unsigned long keyCode;
[NeedsCallerType]
readonly attribute boolean altKey;
[NeedsCallerType]
readonly attribute boolean ctrlKey;
[NeedsCallerType]
readonly attribute boolean shiftKey;
readonly attribute boolean metaKey;
[NeedsCallerType]
boolean getModifierState(DOMString key);
const unsigned long DOM_KEY_LOCATION_STANDARD = 0x00;
const unsigned long DOM_KEY_LOCATION_LEFT = 0x01;
const unsigned long DOM_KEY_LOCATION_RIGHT = 0x02;
const unsigned long DOM_KEY_LOCATION_NUMPAD = 0x03;
readonly attribute unsigned long location;
readonly attribute boolean repeat;
readonly attribute boolean isComposing;
readonly attribute DOMString key;
[NeedsCallerType]
readonly attribute DOMString code;
Bug 1479964 - Set KeyboardEvent.keyCode and KeyboardEvent.charCode to same value if the event is "keypress" event r=smaug Chrome sets both KeyboardEvent.keyCode and KeyboardEvent.charCode of "keypress" event to same value. On the other hand, our traditional behavior is, sets one of them to 0. Therefore, we need to set keyCode value to charCode value if the keypress event is caused by a non-function key, i.e., it may be a printable key with specific modifier state and/or different keyboard layout for compatibility with Chrome. Similarly, we need to set charCode value to keyCode value if the keypress event is caused by a function key which is not mapped to producing a character. Note that this hack is for compatibility with Chrome. So, for now, it's enough to change the behavior only for "keypress" event handlers in web content. If we completely change the behavior, we need to fix a lot of default handlers and mochitests too. However, it's really difficult because default handlers check whether keypress events are printable or not with following code: > if (event.charCode && > !event.altKey && !event.ctrlKey && !event.metaKey) { or > if (!event.keyCode && > !event.altKey && !event.ctrlKey && !event.metaKey) { So, until we stop dispatching "keypress" events for non-printable keys, we need complicated check in each of them. And also note that this patch changes the behavior of KeyboardEvent::KeyCode() when spoofing is enabled and the instance is initialized by initKeyEvent() or initKeyboardEvent(). That was changed by bug 1222285 unexpectedly and keeping the behavior makes patched code really ugly. Therefore, this takes back the old behavior even if spoofing is enabled. Differential Revision: https://phabricator.services.mozilla.com/D7974 --HG-- extra : moz-landing-system : lando
2018-10-09 07:43:37 +03:00
[Throws, BinaryName="initKeyboardEventJS"]
void initKeyboardEvent(DOMString typeArg,
optional boolean bubblesArg = false,
optional boolean cancelableArg = false,
optional Window? viewArg = null,
optional DOMString keyArg = "",
optional unsigned long locationArg = 0,
optional boolean ctrlKey = false,
optional boolean altKey = false,
optional boolean shiftKey = false,
optional boolean metaKey = false);
// This returns the initialized dictionary for generating a
// same-type keyboard event
[Cached, ChromeOnly, Constant]
readonly attribute KeyboardEventInit initDict;
};
dictionary KeyboardEventInit : EventModifierInit
{
DOMString key = "";
DOMString code = "";
unsigned long location = 0;
boolean repeat = false;
boolean isComposing = false;
// legacy attributes
unsigned long charCode = 0;
unsigned long keyCode = 0;
unsigned long which = 0;
};
// Mozilla extensions
KeyboardEvent implements KeyEvent;