gecko-dev/dom/events/KeyboardEvent.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

391 строка
14 KiB
C++
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04:00
/* 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/. */
#include "mozilla/dom/KeyboardEvent.h"
#include "mozilla/TextEvents.h"
#include "nsContentUtils.h"
#include "prtime.h"
namespace mozilla::dom {
KeyboardEvent::KeyboardEvent(EventTarget* aOwner, nsPresContext* aPresContext,
WidgetKeyboardEvent* aEvent)
: UIEvent(aOwner, aPresContext,
aEvent ? aEvent
: new WidgetKeyboardEvent(false, eVoidEvent, nullptr)),
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
mInitializedByJS(false),
mInitializedByCtor(false),
mInitializedWhichValue(0) {
if (aEvent) {
mEventIsInternal = false;
} else {
mEventIsInternal = true;
mEvent->mTime = PR_Now();
mEvent->AsKeyboardEvent()->mKeyNameIndex = KEY_NAME_INDEX_USE_STRING;
}
}
bool KeyboardEvent::AltKey(CallerType aCallerType) {
bool altState = mEvent->AsKeyboardEvent()->IsAlt();
if (!ShouldResistFingerprinting(aCallerType)) {
return altState;
}
// We need to give a spoofed state for Alt key since it could be used as a
// modifier key in certain keyboard layout. For example, the '@' key for
// German keyboard for MAC is Alt+L.
return GetSpoofedModifierStates(Modifier::MODIFIER_ALT, altState);
}
bool KeyboardEvent::CtrlKey(CallerType aCallerType) {
// We don't spoof this key when privacy.resistFingerprinting
// is enabled, because it is often used for command key
// combinations in web apps.
return mEvent->AsKeyboardEvent()->IsControl();
}
bool KeyboardEvent::ShiftKey(CallerType aCallerType) {
bool shiftState = mEvent->AsKeyboardEvent()->IsShift();
if (!ShouldResistFingerprinting(aCallerType)) {
return shiftState;
}
return GetSpoofedModifierStates(Modifier::MODIFIER_SHIFT, shiftState);
}
bool KeyboardEvent::MetaKey() {
// We don't spoof this key when privacy.resistFingerprinting
// is enabled, because it is often used for command key
// combinations in web apps.
return mEvent->AsKeyboardEvent()->IsMeta();
}
bool KeyboardEvent::Repeat() { return mEvent->AsKeyboardEvent()->mIsRepeat; }
bool KeyboardEvent::IsComposing() {
return mEvent->AsKeyboardEvent()->mIsComposing;
}
void KeyboardEvent::GetKey(nsAString& aKeyName) const {
mEvent->AsKeyboardEvent()->GetDOMKeyName(aKeyName);
}
void KeyboardEvent::GetCode(nsAString& aCodeName, CallerType aCallerType) {
if (!ShouldResistFingerprinting(aCallerType)) {
mEvent->AsKeyboardEvent()->GetDOMCodeName(aCodeName);
return;
}
// When fingerprinting resistance is enabled, we will give a spoofed code
// according to the content-language of the document.
nsCOMPtr<Document> doc = GetDocument();
nsRFPService::GetSpoofedCode(doc, mEvent->AsKeyboardEvent(), aCodeName);
}
void KeyboardEvent::GetInitDict(KeyboardEventInit& aParam) {
GetKey(aParam.mKey);
GetCode(aParam.mCode);
aParam.mLocation = Location();
aParam.mRepeat = Repeat();
aParam.mIsComposing = IsComposing();
// legacy attributes
aParam.mKeyCode = KeyCode();
aParam.mCharCode = CharCode();
aParam.mWhich = Which();
// modifiers from EventModifierInit
aParam.mCtrlKey = CtrlKey();
aParam.mShiftKey = ShiftKey();
aParam.mAltKey = AltKey();
aParam.mMetaKey = MetaKey();
WidgetKeyboardEvent* internalEvent = mEvent->AsKeyboardEvent();
aParam.mModifierAltGraph = internalEvent->IsAltGraph();
aParam.mModifierCapsLock = internalEvent->IsCapsLocked();
aParam.mModifierFn = internalEvent->IsFn();
aParam.mModifierFnLock = internalEvent->IsFnLocked();
aParam.mModifierNumLock = internalEvent->IsNumLocked();
aParam.mModifierOS = internalEvent->IsOS();
aParam.mModifierScrollLock = internalEvent->IsScrollLocked();
aParam.mModifierSymbol = internalEvent->IsSymbol();
aParam.mModifierSymbolLock = internalEvent->IsSymbolLocked();
// EventInit
aParam.mBubbles = internalEvent->mFlags.mBubbles;
aParam.mCancelable = internalEvent->mFlags.mCancelable;
}
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
bool KeyboardEvent::ShouldUseSameValueForCharCodeAndKeyCode(
const WidgetKeyboardEvent& aWidgetKeyboardEvent,
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
CallerType aCallerType) const {
// - If this event is initialized by JS, we don't need to return same value
// for keyCode and charCode since they can be initialized separately.
// - If this is not a keypress event, we shouldn't return same value for
// keyCode and charCode.
// - If we need to return legacy keyCode and charCode values for the web
// app due to in the blacklist.
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
// - If this event is referred by default handler, i.e., the caller is
// system or this event is now in the system group, we don't need to use
// hack for web-compat.
if (mInitializedByJS || aWidgetKeyboardEvent.mMessage != eKeyPress ||
aWidgetKeyboardEvent.mUseLegacyKeyCodeAndCharCodeValues ||
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
aCallerType == CallerType::System ||
aWidgetKeyboardEvent.mFlags.mInSystemGroup) {
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
return false;
}
MOZ_ASSERT(aCallerType == CallerType::NonSystem);
return StaticPrefs::
dom_keyboardevent_keypress_set_keycode_and_charcode_to_same_value();
}
uint32_t KeyboardEvent::CharCode(CallerType aCallerType) {
WidgetKeyboardEvent* widgetKeyboardEvent = mEvent->AsKeyboardEvent();
if (mInitializedByJS) {
// If this is initialized by Ctor, we should return the initialized value.
if (mInitializedByCtor) {
return widgetKeyboardEvent->mCharCode;
}
// Otherwise, i.e., initialized by InitKey*Event(), we should return the
// initialized value only when eKeyPress or eAccessKeyNotFound event.
// Although this is odd, but our traditional behavior.
return widgetKeyboardEvent->mMessage == eKeyPress ||
widgetKeyboardEvent->mMessage == eAccessKeyNotFound
? widgetKeyboardEvent->mCharCode
: 0;
}
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
// If the key is a function key, we should return the result of KeyCode()
// even from CharCode(). Otherwise, i.e., the key may be a printable
// key or actually a printable key, we should return the given charCode
// value.
if (widgetKeyboardEvent->mKeyNameIndex != KEY_NAME_INDEX_USE_STRING &&
ShouldUseSameValueForCharCodeAndKeyCode(*widgetKeyboardEvent,
aCallerType)) {
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
return ComputeTraditionalKeyCode(*widgetKeyboardEvent, aCallerType);
}
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
return widgetKeyboardEvent->mCharCode;
}
uint32_t KeyboardEvent::KeyCode(CallerType aCallerType) {
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
WidgetKeyboardEvent* widgetKeyboardEvent = mEvent->AsKeyboardEvent();
if (mInitializedByJS) {
// If this is initialized by Ctor, we should return the initialized value.
if (mInitializedByCtor) {
return widgetKeyboardEvent->mKeyCode;
}
// Otherwise, i.e., initialized by InitKey*Event(), we should return the
// initialized value only when the event message is a valid keyboard event
// message. Although this is odd, but our traditional behavior.
// NOTE: The fix of bug 1222285 changed the behavior temporarily if
// spoofing is enabled. However, the behavior does not make sense
// since if the event is generated by JS, the behavior shouldn't
// be changed by whether spoofing is enabled or not. Therefore,
// we take back the original behavior.
return widgetKeyboardEvent->HasKeyEventMessage()
? widgetKeyboardEvent->mKeyCode
: 0;
}
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
// If the key is not a function key, i.e., the key may be a printable key
// or a function key mapped as a printable key, we should use charCode value
// for keyCode value if this is a "keypress" event.
if (widgetKeyboardEvent->mKeyNameIndex == KEY_NAME_INDEX_USE_STRING &&
ShouldUseSameValueForCharCodeAndKeyCode(*widgetKeyboardEvent,
aCallerType)) {
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
return widgetKeyboardEvent->mCharCode;
}
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
return ComputeTraditionalKeyCode(*widgetKeyboardEvent, aCallerType);
}
uint32_t KeyboardEvent::ComputeTraditionalKeyCode(
WidgetKeyboardEvent& aKeyboardEvent, CallerType aCallerType) {
if (!ShouldResistFingerprinting(aCallerType)) {
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
return aKeyboardEvent.mKeyCode;
}
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
// In Netscape style (i.e., traditional behavior of Gecko), the keyCode
// should be zero if the char code is given.
if ((mEvent->mMessage == eKeyPress ||
mEvent->mMessage == eAccessKeyNotFound) &&
aKeyboardEvent.mCharCode) {
return 0;
}
// When fingerprinting resistance is enabled, we will give a spoofed keyCode
// according to the content-language of the document.
nsCOMPtr<Document> doc = GetDocument();
uint32_t spoofedKeyCode;
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
if (nsRFPService::GetSpoofedKeyCode(doc, &aKeyboardEvent, spoofedKeyCode)) {
return spoofedKeyCode;
}
return 0;
}
uint32_t KeyboardEvent::Which(CallerType aCallerType) {
// If this event is initialized with ctor, which can have independent value.
if (mInitializedByCtor) {
return mInitializedWhichValue;
}
switch (mEvent->mMessage) {
case eKeyDown:
case eKeyDownOnPlugin:
case eKeyUp:
case eKeyUpOnPlugin:
return KeyCode(aCallerType);
case eKeyPress:
// Special case for 4xp bug 62878. Try to make value of which
// more closely mirror the values that 4.x gave for RETURN and BACKSPACE
{
uint32_t keyCode = mEvent->AsKeyboardEvent()->mKeyCode;
if (keyCode == NS_VK_RETURN || keyCode == NS_VK_BACK) {
return keyCode;
}
return CharCode();
}
default:
break;
}
return 0;
}
uint32_t KeyboardEvent::Location() {
return mEvent->AsKeyboardEvent()->mLocation;
}
// static
already_AddRefed<KeyboardEvent> KeyboardEvent::ConstructorJS(
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
const GlobalObject& aGlobal, const nsAString& aType,
const KeyboardEventInit& aParam) {
nsCOMPtr<EventTarget> target = do_QueryInterface(aGlobal.GetAsSupports());
RefPtr<KeyboardEvent> newEvent = new KeyboardEvent(target, nullptr, nullptr);
newEvent->InitWithKeyboardEventInit(target, aType, aParam);
return newEvent.forget();
}
void KeyboardEvent::InitWithKeyboardEventInit(EventTarget* aOwner,
const nsAString& aType,
const KeyboardEventInit& aParam) {
bool trusted = Init(aOwner);
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
InitKeyEventJS(aType, aParam.mBubbles, aParam.mCancelable, aParam.mView,
false, false, false, false, aParam.mKeyCode, aParam.mCharCode);
InitModifiers(aParam);
SetTrusted(trusted);
mDetail = aParam.mDetail;
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
mInitializedByJS = true;
mInitializedByCtor = true;
mInitializedWhichValue = aParam.mWhich;
WidgetKeyboardEvent* internalEvent = mEvent->AsKeyboardEvent();
internalEvent->mLocation = aParam.mLocation;
internalEvent->mIsRepeat = aParam.mRepeat;
internalEvent->mIsComposing = aParam.mIsComposing;
internalEvent->mKeyNameIndex =
WidgetKeyboardEvent::GetKeyNameIndex(aParam.mKey);
if (internalEvent->mKeyNameIndex == KEY_NAME_INDEX_USE_STRING) {
internalEvent->mKeyValue = aParam.mKey;
}
internalEvent->mCodeNameIndex =
WidgetKeyboardEvent::GetCodeNameIndex(aParam.mCode);
if (internalEvent->mCodeNameIndex == CODE_NAME_INDEX_USE_STRING) {
internalEvent->mCodeValue = aParam.mCode;
}
}
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
void KeyboardEvent::InitKeyEventJS(const nsAString& aType, bool aCanBubble,
bool aCancelable, nsGlobalWindowInner* aView,
bool aCtrlKey, bool aAltKey, bool aShiftKey,
bool aMetaKey, uint32_t aKeyCode,
uint32_t aCharCode) {
NS_ENSURE_TRUE_VOID(!mEvent->mFlags.mIsBeingDispatched);
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
mInitializedByJS = true;
mInitializedByCtor = false;
UIEvent::InitUIEvent(aType, aCanBubble, aCancelable, aView, 0);
WidgetKeyboardEvent* keyEvent = mEvent->AsKeyboardEvent();
keyEvent->InitBasicModifiers(aCtrlKey, aAltKey, aShiftKey, aMetaKey);
keyEvent->mKeyCode = aKeyCode;
keyEvent->mCharCode = aCharCode;
}
void KeyboardEvent::InitKeyboardEventJS(
const nsAString& aType, bool aCanBubble, bool aCancelable,
nsGlobalWindowInner* aView, const nsAString& aKey, uint32_t aLocation,
bool aCtrlKey, bool aAltKey, bool aShiftKey, bool aMetaKey) {
NS_ENSURE_TRUE_VOID(!mEvent->mFlags.mIsBeingDispatched);
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
mInitializedByJS = true;
mInitializedByCtor = false;
UIEvent::InitUIEvent(aType, aCanBubble, aCancelable, aView, 0);
WidgetKeyboardEvent* keyEvent = mEvent->AsKeyboardEvent();
keyEvent->InitBasicModifiers(aCtrlKey, aAltKey, aShiftKey, aMetaKey);
keyEvent->mLocation = aLocation;
keyEvent->mKeyNameIndex = KEY_NAME_INDEX_USE_STRING;
keyEvent->mKeyValue = aKey;
}
bool KeyboardEvent::ShouldResistFingerprinting(CallerType aCallerType) {
// There are five situations we don't need to spoof this keyboard event.
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
// 1. This event is initialized by scripts.
// 2. This event is from Numpad.
// 3. This event is in the system group.
// 4. The caller type is system.
// 5. The pref privcy.resistFingerprinting' is false, we fast return here
// since we don't need to do any QI of following codes.
if (mInitializedByJS || aCallerType == CallerType::System ||
mEvent->mFlags.mInSystemGroup ||
!nsContentUtils::ShouldResistFingerprinting() ||
mEvent->AsKeyboardEvent()->mLocation ==
KeyboardEvent_Binding::DOM_KEY_LOCATION_NUMPAD) {
return false;
}
nsCOMPtr<Document> doc = GetDocument();
return doc && !nsContentUtils::IsChromeDoc(doc);
}
bool KeyboardEvent::GetSpoofedModifierStates(const Modifiers aModifierKey,
const bool aRawModifierState) {
bool spoofedState;
nsCOMPtr<Document> doc = GetDocument();
if (nsRFPService::GetSpoofedModifierStates(doc, mEvent->AsKeyboardEvent(),
aModifierKey, spoofedState)) {
return spoofedState;
}
return aRawModifierState;
}
} // namespace mozilla::dom
using namespace mozilla;
using namespace mozilla::dom;
already_AddRefed<KeyboardEvent> NS_NewDOMKeyboardEvent(
EventTarget* aOwner, nsPresContext* aPresContext,
WidgetKeyboardEvent* aEvent) {
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
RefPtr<KeyboardEvent> it = new KeyboardEvent(aOwner, aPresContext, aEvent);
return it.forget();
}