2015-05-03 22:32:37 +03:00
|
|
|
/* -*- 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/. */
|
2004-08-20 22:09:19 +04:00
|
|
|
|
2014-02-27 14:51:13 +04:00
|
|
|
#include "mozilla/dom/KeyboardEvent.h"
|
2013-09-25 15:21:19 +04:00
|
|
|
#include "mozilla/TextEvents.h"
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
#include "nsContentUtils.h"
|
2014-02-27 14:51:13 +04:00
|
|
|
#include "prtime.h"
|
2004-08-20 22:09:19 +04:00
|
|
|
|
2020-11-04 20:04:01 +03:00
|
|
|
namespace mozilla::dom {
|
2013-10-01 11:22:58 +04:00
|
|
|
|
2014-02-27 14:51:13 +04:00
|
|
|
KeyboardEvent::KeyboardEvent(EventTarget* aOwner, nsPresContext* aPresContext,
|
|
|
|
WidgetKeyboardEvent* aEvent)
|
2014-02-28 18:58:43 +04:00
|
|
|
: UIEvent(aOwner, aPresContext,
|
2015-08-26 15:56:59 +03:00
|
|
|
aEvent ? aEvent
|
2015-08-29 02:58:26 +03:00
|
|
|
: 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),
|
2014-04-14 10:37:47 +04:00
|
|
|
mInitializedByCtor(false),
|
2014-11-03 10:05:32 +03:00
|
|
|
mInitializedWhichValue(0) {
|
2004-08-20 22:09:19 +04:00
|
|
|
if (aEvent) {
|
2011-10-17 18:59:28 +04:00
|
|
|
mEventIsInternal = false;
|
2004-08-20 22:09:19 +04:00
|
|
|
} else {
|
2011-10-17 18:59:28 +04:00
|
|
|
mEventIsInternal = true;
|
2016-03-28 07:29:42 +03:00
|
|
|
mEvent->mTime = PR_Now();
|
2013-10-29 08:14:42 +04:00
|
|
|
mEvent->AsKeyboardEvent()->mKeyNameIndex = KEY_NAME_INDEX_USE_STRING;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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);
|
2013-10-18 10:10:26 +04:00
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
bool KeyboardEvent::CtrlKey(CallerType aCallerType) {
|
2018-03-06 00:23:00 +03:00
|
|
|
// 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();
|
2013-10-18 10:10:26 +04:00
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
bool KeyboardEvent::ShiftKey(CallerType aCallerType) {
|
|
|
|
bool shiftState = mEvent->AsKeyboardEvent()->IsShift();
|
|
|
|
|
|
|
|
if (!ShouldResistFingerprinting(aCallerType)) {
|
|
|
|
return shiftState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return GetSpoofedModifierStates(Modifier::MODIFIER_SHIFT, shiftState);
|
2013-10-18 10:10:26 +04:00
|
|
|
}
|
|
|
|
|
2014-02-27 14:51:13 +04:00
|
|
|
bool KeyboardEvent::MetaKey() {
|
2018-03-06 00:23:00 +03:00
|
|
|
// We don't spoof this key when privacy.resistFingerprinting
|
|
|
|
// is enabled, because it is often used for command key
|
|
|
|
// combinations in web apps.
|
2013-10-18 10:10:26 +04:00
|
|
|
return mEvent->AsKeyboardEvent()->IsMeta();
|
|
|
|
}
|
|
|
|
|
2013-11-07 15:17:32 +04:00
|
|
|
bool KeyboardEvent::Repeat() { return mEvent->AsKeyboardEvent()->mIsRepeat; }
|
|
|
|
|
2014-04-10 11:11:36 +04:00
|
|
|
bool KeyboardEvent::IsComposing() {
|
|
|
|
return mEvent->AsKeyboardEvent()->mIsComposing;
|
|
|
|
}
|
|
|
|
|
2018-02-09 19:17:09 +03:00
|
|
|
void KeyboardEvent::GetKey(nsAString& aKeyName) const {
|
2014-12-30 04:47:53 +03:00
|
|
|
mEvent->AsKeyboardEvent()->GetDOMKeyName(aKeyName);
|
2013-04-24 07:49:46 +04:00
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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.
|
2019-01-02 16:05:23 +03:00
|
|
|
nsCOMPtr<Document> doc = GetDocument();
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
|
|
|
|
nsRFPService::GetSpoofedCode(doc, mEvent->AsKeyboardEvent(), aCodeName);
|
2014-05-25 06:08:58 +04:00
|
|
|
}
|
|
|
|
|
2016-03-15 08:46:29 +03:00
|
|
|
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(
|
2018-11-07 09:39:10 +03:00
|
|
|
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.
|
2018-11-07 09:39:10 +03:00
|
|
|
// - 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.
|
2018-11-07 09:39:10 +03:00
|
|
|
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 ||
|
2018-11-07 09:39:10 +03:00
|
|
|
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;
|
2014-04-14 10:37:47 +04:00
|
|
|
}
|
|
|
|
|
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 &&
|
2018-11-07 09:39:10 +03:00
|
|
|
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);
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
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;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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;
|
2014-04-14 10:37:47 +04:00
|
|
|
}
|
|
|
|
|
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 &&
|
2018-11-07 09:39:10 +03:00
|
|
|
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 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
}
|
|
|
|
|
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) {
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
|
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) {
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When fingerprinting resistance is enabled, we will give a spoofed keyCode
|
|
|
|
// according to the content-language of the document.
|
2019-01-02 16:05:23 +03:00
|
|
|
nsCOMPtr<Document> doc = GetDocument();
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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)) {
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
return spoofedKeyCode;
|
|
|
|
}
|
|
|
|
|
2013-04-21 03:48:55 +04:00
|
|
|
return 0;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
|
2018-02-21 00:51:00 +03:00
|
|
|
uint32_t KeyboardEvent::Which(CallerType aCallerType) {
|
2014-04-14 10:37:47 +04:00
|
|
|
// If this event is initialized with ctor, which can have independent value.
|
|
|
|
if (mInitializedByCtor) {
|
2014-11-03 10:05:32 +03:00
|
|
|
return mInitializedWhichValue;
|
2014-04-14 10:37:47 +04:00
|
|
|
}
|
|
|
|
|
2015-08-22 04:34:51 +03:00
|
|
|
switch (mEvent->mMessage) {
|
2015-08-29 02:58:27 +03:00
|
|
|
case eKeyDown:
|
2016-04-22 19:22:49 +03:00
|
|
|
case eKeyDownOnPlugin:
|
2015-08-29 02:58:27 +03:00
|
|
|
case eKeyUp:
|
2016-04-22 19:22:49 +03:00
|
|
|
case eKeyUpOnPlugin:
|
2018-02-21 00:51:00 +03:00
|
|
|
return KeyCode(aCallerType);
|
2015-08-29 02:58:27 +03:00
|
|
|
case eKeyPress:
|
2004-08-20 22:09:19 +04:00
|
|
|
// 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
|
|
|
|
{
|
2016-05-12 11:13:49 +03:00
|
|
|
uint32_t keyCode = mEvent->AsKeyboardEvent()->mKeyCode;
|
2004-08-20 22:09:19 +04:00
|
|
|
if (keyCode == NS_VK_RETURN || keyCode == NS_VK_BACK) {
|
2013-04-21 03:48:55 +04:00
|
|
|
return keyCode;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
2013-04-21 03:48:55 +04:00
|
|
|
return CharCode();
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
2015-08-26 15:56:59 +03:00
|
|
|
default:
|
|
|
|
break;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
|
2013-04-21 03:48:55 +04:00
|
|
|
return 0;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
|
2014-02-27 14:51:13 +04:00
|
|
|
uint32_t KeyboardEvent::Location() {
|
2016-05-12 12:17:22 +03:00
|
|
|
return mEvent->AsKeyboardEvent()->mLocation;
|
2013-10-18 10:10:24 +04:00
|
|
|
}
|
|
|
|
|
2014-04-14 10:37:47 +04:00
|
|
|
// 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,
|
2019-09-11 17:35:28 +03:00
|
|
|
const KeyboardEventInit& aParam) {
|
2014-04-14 10:37:47 +04:00
|
|
|
nsCOMPtr<EventTarget> target = do_QueryInterface(aGlobal.GetAsSupports());
|
|
|
|
RefPtr<KeyboardEvent> newEvent = new KeyboardEvent(target, nullptr, nullptr);
|
2019-09-11 17:35:28 +03:00
|
|
|
newEvent->InitWithKeyboardEventInit(target, aType, aParam);
|
2014-11-03 10:05:32 +03:00
|
|
|
|
|
|
|
return newEvent.forget();
|
|
|
|
}
|
|
|
|
|
|
|
|
void KeyboardEvent::InitWithKeyboardEventInit(EventTarget* aOwner,
|
|
|
|
const nsAString& aType,
|
2019-09-11 17:35:28 +03:00
|
|
|
const KeyboardEventInit& aParam) {
|
2014-11-03 10:05:32 +03:00
|
|
|
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);
|
2015-04-13 10:16:13 +03:00
|
|
|
InitModifiers(aParam);
|
2014-11-03 10:05:32 +03:00
|
|
|
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;
|
2014-11-03 10:05:32 +03:00
|
|
|
mInitializedByCtor = true;
|
|
|
|
mInitializedWhichValue = aParam.mWhich;
|
|
|
|
|
|
|
|
WidgetKeyboardEvent* internalEvent = mEvent->AsKeyboardEvent();
|
2016-05-12 12:17:22 +03:00
|
|
|
internalEvent->mLocation = aParam.mLocation;
|
2014-04-14 10:37:47 +04:00
|
|
|
internalEvent->mIsRepeat = aParam.mRepeat;
|
|
|
|
internalEvent->mIsComposing = aParam.mIsComposing;
|
2015-02-19 09:50:19 +03:00
|
|
|
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;
|
|
|
|
}
|
2014-04-14 10:37:47 +04:00
|
|
|
}
|
|
|
|
|
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) {
|
2018-02-09 19:17:09 +03:00
|
|
|
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;
|
2016-10-30 22:30:06 +03:00
|
|
|
|
2016-01-30 20:05:36 +03:00
|
|
|
UIEvent::InitUIEvent(aType, aCanBubble, aCancelable, aView, 0);
|
2004-08-20 22:09:19 +04:00
|
|
|
|
2013-10-18 10:10:24 +04:00
|
|
|
WidgetKeyboardEvent* keyEvent = mEvent->AsKeyboardEvent();
|
2012-04-25 07:00:02 +04:00
|
|
|
keyEvent->InitBasicModifiers(aCtrlKey, aAltKey, aShiftKey, aMetaKey);
|
2016-05-12 11:13:49 +03:00
|
|
|
keyEvent->mKeyCode = aKeyCode;
|
2016-05-13 10:06:18 +03:00
|
|
|
keyEvent->mCharCode = aCharCode;
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|
|
|
|
|
2019-09-11 17:35:28 +03:00
|
|
|
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) {
|
2017-08-06 16:52:39 +03:00
|
|
|
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;
|
2017-08-06 16:52:39 +03:00
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
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.
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
// 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 ==
|
2018-06-26 00:20:54 +03:00
|
|
|
KeyboardEvent_Binding::DOM_KEY_LOCATION_NUMPAD) {
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-02 16:05:23 +03:00
|
|
|
nsCOMPtr<Document> doc = GetDocument();
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
|
|
|
|
return doc && !nsContentUtils::IsChromeDoc(doc);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool KeyboardEvent::GetSpoofedModifierStates(const Modifiers aModifierKey,
|
|
|
|
const bool aRawModifierState) {
|
|
|
|
bool spoofedState;
|
2019-01-02 16:05:23 +03:00
|
|
|
nsCOMPtr<Document> doc = GetDocument();
|
Bug 1222285 - Part 1: Spoofing the keyboard event to mimc a certain keyboard layout according to the content-language of the document when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki,smaug
This patch makes Firefox to spoof keyboardEvent.code, keyboardEvent.keycode and
modifier states, for 'Shift', 'Alt', 'Control' and 'AltGraph', when 'privacy.resistFingerprinting'
is true. Firefox will spoof keyboard events as a certain keyboard layout according
to the content language of the document, for example, we use US English keyboard for
English content. Right now, it only supports English contents, we will add more
support for more languages later. The spoofing only affects content, chrome
can still see real keyboard events.
MozReview-Commit-ID: 40JPvwLmMMB
--HG--
extra : rebase_source : 870224ba4f87b3e336c5b061ac6859dd1c48c4f2
2017-08-29 06:33:27 +03:00
|
|
|
|
|
|
|
if (nsRFPService::GetSpoofedModifierStates(doc, mEvent->AsKeyboardEvent(),
|
|
|
|
aModifierKey, spoofedState)) {
|
|
|
|
return spoofedState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return aRawModifierState;
|
|
|
|
}
|
|
|
|
|
2020-11-04 20:04:01 +03:00
|
|
|
} // namespace mozilla::dom
|
2014-02-27 14:51:13 +04:00
|
|
|
|
|
|
|
using namespace mozilla;
|
|
|
|
using namespace mozilla::dom;
|
|
|
|
|
2015-08-12 14:39:31 +03:00
|
|
|
already_AddRefed<KeyboardEvent> NS_NewDOMKeyboardEvent(
|
2014-02-27 14:51:13 +04:00
|
|
|
EventTarget* aOwner, nsPresContext* aPresContext,
|
|
|
|
WidgetKeyboardEvent* aEvent) {
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<KeyboardEvent> it = new KeyboardEvent(aOwner, aPresContext, aEvent);
|
2015-08-12 14:39:31 +03:00
|
|
|
return it.forget();
|
2004-08-20 22:09:19 +04:00
|
|
|
}
|