gecko-dev/dom/events/KeyboardEvent.h

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

134 строки
5.2 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/. */
#ifndef mozilla_dom_KeyboardEvent_h_
#define mozilla_dom_KeyboardEvent_h_
#include "mozilla/dom/UIEvent.h"
#include "mozilla/dom/KeyboardEventBinding.h"
#include "mozilla/EventForwards.h"
#include "nsRFPService.h"
namespace mozilla {
namespace dom {
class KeyboardEvent : public UIEvent {
public:
KeyboardEvent(EventTarget* aOwner, nsPresContext* aPresContext,
WidgetKeyboardEvent* aEvent);
NS_INLINE_DECL_REFCOUNTING_INHERITED(KeyboardEvent, UIEvent)
virtual KeyboardEvent* AsKeyboardEvent() override { return this; }
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
static already_AddRefed<KeyboardEvent> ConstructorJS(
const GlobalObject& aGlobal, const nsAString& aType,
const KeyboardEventInit& aParam, ErrorResult& aRv);
virtual JSObject* WrapObjectInternal(
JSContext* aCx, JS::Handle<JSObject*> aGivenProto) override {
return KeyboardEvent_Binding::Wrap(aCx, this, aGivenProto);
}
bool AltKey(CallerType aCallerType = CallerType::System);
bool CtrlKey(CallerType aCallerType = CallerType::System);
bool ShiftKey(CallerType aCallerType = CallerType::System);
bool MetaKey();
bool GetModifierState(const nsAString& aKey,
CallerType aCallerType = CallerType::System) {
bool modifierState = GetModifierStateInternal(aKey);
if (!ShouldResistFingerprinting(aCallerType)) {
return modifierState;
}
Modifiers modifier = WidgetInputEvent::GetModifier(aKey);
return GetSpoofedModifierStates(modifier, modifierState);
}
bool Repeat();
bool IsComposing();
void GetKey(nsAString& aKey) const;
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
uint32_t CharCode(CallerType aCallerType = CallerType::System);
uint32_t KeyCode(CallerType aCallerType = CallerType::System);
virtual uint32_t Which(CallerType aCallerType = CallerType::System) override;
uint32_t Location();
void GetCode(nsAString& aCode, CallerType aCallerType = CallerType::System);
void GetInitDict(KeyboardEventInit& aParam);
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 InitKeyEventJS(const nsAString& aType, bool aCanBubble, bool aCancelable,
nsGlobalWindowInner* aView, bool aCtrlKey, bool aAltKey,
bool aShiftKey, bool aMetaKey, uint32_t aKeyCode,
uint32_t aCharCode);
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 InitKeyboardEventJS(const nsAString& aType, bool aCanBubble,
bool aCancelable, nsGlobalWindowInner* aView,
const nsAString& aKey, uint32_t aLocation,
bool aCtrlKey, bool aAltKey, bool aShiftKey,
bool aMetaKey, ErrorResult& aRv);
protected:
~KeyboardEvent() {}
void InitWithKeyboardEventInit(EventTarget* aOwner, const nsAString& aType,
const KeyboardEventInit& aParam,
ErrorResult& aRv);
private:
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
// True, if the instance is initialized by JS.
bool mInitializedByJS;
// True, if the instance is initialized by Ctor.
bool mInitializedByCtor;
// If the instance is created with Constructor(), which may have independent
// value. mInitializedWhichValue stores it. I.e., this is invalid when
// mInitializedByCtor is false.
uint32_t mInitializedWhichValue;
// This method returns the boolean to indicate whether spoofing keyboard
// event for fingerprinting resistance. It will return true when pref
// 'privacy.resistFingerprinting' is true and the event target is content.
// Otherwise, it will return false.
bool ShouldResistFingerprinting(CallerType aCallerType);
// This method returns the spoofed modifier state of the given modifier key
// for fingerprinting resistance.
bool GetSpoofedModifierStates(const Modifiers aModifierKey,
const bool aRawModifierState);
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
/**
* ComputeTraditionalKeyCode() computes traditional keyCode value. I.e.,
* returns 0 if this event should return non-zero from CharCode().
* In spite of the name containing "traditional", this computes spoof
* keyCode value if user wants it.
*
* @param aKeyboardEvent Should be |*mEvent->AsKeyboardEvent()|.
* @param aCallerType Set caller type of KeyCode() or CharCode().
* @return If traditional charCode value is 0, returns
* the raw keyCode value or spoof keyCode value.
* Otherwise, 0.
*/
uint32_t ComputeTraditionalKeyCode(WidgetKeyboardEvent& aKeyboardEvent,
CallerType aCallerType);
/**
* ShouldUseSameValueForCharCodeAndKeyCode() returns true if KeyCode() and
* CharCode() should return same value.
*/
bool ShouldUseSameValueForCharCodeAndKeyCode(
const WidgetKeyboardEvent& aKeyboardEvent, CallerType aCallerType) const;
};
} // namespace dom
} // namespace mozilla
already_AddRefed<mozilla::dom::KeyboardEvent> NS_NewDOMKeyboardEvent(
mozilla::dom::EventTarget* aOwner, nsPresContext* aPresContext,
mozilla::WidgetKeyboardEvent* aEvent);
#endif // mozilla_dom_KeyboardEvent_h_