VSync on Wayland is a bit tricky as we can get only "last VSync" event signal with
CLOCK_MONOTONIC timestamp or none (if application is hidden/minimized).
That means we should draw a next frame at "last Vsync + frame delay" time and also
approximate next VSync event when we don't get any.
MozReview-Commit-ID: FI3Z4nkmDNK
--HG--
extra : rebase_source : 8a0f6148990cf4e7ad26ff287eadff87cb0215fc
Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
Different from Windows and macOS, we cannot check if active keyboard layout
works as "IME" actually. Therefore, this patch add the telemetry probe
to the dispatcher of eCompositionStart. However, composition string is also
used by some Wester keyboard layouts which have dead keys. So, the meaning
of the result is deferent from the other platforms, but it must be useful
information which IM (e.g., fcitx, ibus) is used by most users.
MozReview-Commit-ID: A7vYuGtcrRw
--HG--
extra : rebase_source : 1f0948b58b999eee4b539d7db05d455b34f4be72
This patch adds a telemetry probe to collect Input Source ID or Bundle ID of
IME when an IME open mode is selected by user. Input Source ID includes
input mode of IME, but Bundle ID does not so. In most languages, we need
to collect the former, but only for Japanese IME, we need to collect the
latter because non-Japanese IME's input mode is "how to input characters".
So, the input mode is important. However, Japanese IME's input mode is
"to input which type of characters". So, Japanese IME user may use multiple
input modes but we need only the IME mode. If we'd collect number of
each input mode users of Japanese language, it'd be difficult to count
how many users actually used typical Japanese IME since somebody may use
only a mode, some others may use only different modes.
So, this patch collects Input Source ID when non-Japanese IME is open and
Bundle ID when Japanese IME is open.
MozReview-Commit-ID: CltLrWVGyRk
--HG--
extra : rebase_source : 752dd00c4e43bda9586ed3ba498636bf5069ead2
We always struggle with a lot of IME bugs on Windows. Currently, any IME
vendors should've already released TIP for TSF rather than legacy IMM-IME
since IMM-IME is not available on UWP apps. Additionally, due to API
limitation, it's difficult to get human-friendly name of IMM-IME. So, let's
collect only TIP names of TSF on Windows. This must be enough.
Note that we cannot get common-English name even though the API to retrieve
TIP name taking language code. Therefore, a TIP may be collected with
different name, e.g., one is Japanese name and the other is English name.
If we collect GUIDs of TIP, we can avoid this issue. However, it's
difficult to collect both GUID and human-friendly name since Telemetry
key is up to 72 characters.
Currently, I give up to avoid this duplicated issue. Perhaps, this is not
so serious issue since most TIP users must match language of TIP and their
system language settings. Therefore, this patch collects Locale ID of
TIP and description of it. Locale ID is necessary because some TIPs may be
named same name for different languages. For example, both Japanese and
Hangul IMEs of Microsoft are named as "Microsoft IME".
MozReview-Commit-ID: IeSxfeqS62a
--HG--
extra : rebase_source : b269ce3c41f7a998193972afb31183a61d3948be
Summary:
document.addEventListener("shadowrootattached", e => {
// Do stuff with composedTarget.
});
I didn't bother to add tests for the event itself since this is going to get
tested in bug 1449333, but I can look into writing a chrome mochitest if you
want.
Test Plan: See above.
Reviewers: smaug
Bug #: 1470545
Differential Revision: https://phabricator.services.mozilla.com/D1777
MozReview-Commit-ID: 55cVMSsznMS
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
I'm replacing non-failing calls to NS_NOTREACHED with MOZ_ASSERT_UNREACHABLE, but this NS_NOTREACHED fails when running the browser/base/content/test/general/browser_tab_dragdrop2.js test because mContainer is unexpectedly *not* null. This is bug 1469183.
This patch DOES NOT fix the cause of the assertion failure. It just replaces this failing NS_NOTREACHED with NS_ERROR because I can't replace with a fatal MOZ_ASSERT_UNREACHABLE.
MozReview-Commit-ID: KeVjvKGihxZ
--HG--
extra : rebase_source : dc08a8e15d1e98cda0fa755be43c6d06910bfbe8
extra : intermediate-source : 562cc0bfc636f29b1708acd3284567bb8492e030
extra : source : 4f14f18eccd6bb18ed92f1d39a265a30ccdd21a1
|name| is too generic but the scope is too wide in test_keycodes.xul.
So, let's rename it to |currentTestName|.
MozReview-Commit-ID: JvEDhRhKYCU
--HG--
extra : rebase_source : 15e06fabddeddb8e79198aa9f135e2951976aa8e
When AltGr key is pressed, following messages come:
1. WM_KEYDOWN for ControlLeft
2. WM_KEYDOWN for AltLeft
3. WM_SYSKEYUP for ControlLeft
4. WM_KEYUP for AltLeft
In these key sequence, KeyboardEvent.key value of keydown event at #2 and keyup
event at #4 should be "AltGraph". This patch fixes the key value and
adding new test into test_keycodes.xul to check the behavior with
SynthesizeNativeKey().
MozReview-Commit-ID: JZ6WednB8la
--HG--
extra : rebase_source : 596371ede89e90c23f7e842b26ec8155b911fe60
Users can emulate AltGr key with pressing both Ctrl key and Alt key on Windows
since AltGr is represented as so in Windows and physical keyboard may not have
AltRight key.
If user emulates AltGr key, we should set MODIFIER_ALTGRAPH to a set of
keyboard events for printable keys only when the key press produces
character(s) or a dead key. For example:
1. ControlLeft keydown event should make ctrlKey true.
2. AltLeft keydown event should make altKey true (not AltGraph state).
3. ctrlKey and altKey of printable keydown, keypress and keyup events should be
set to false, but getModifierState("AltGraph") should return true.
4. AltLeft keyup event should make altKey false.
5. ControlLeft keyup event should make ctrlKey false.
(If AltLeft key is pressed first, altKey of AltLeft keydown is true and
both altKey and ctrlKey of the following ControlLeft keydown are true as
usual.)
MozReview-Commit-ID: 8Km8GXPDQw1
--HG--
extra : rebase_source : f4924f075c68361c8ce563910280ea24774c519f
KeyboardLayout::InitNativeKey() takes |const ModifierKeyState&| as its
argument with NativeKey reference and it calls some internal methods with
the given ModifierKeyState without any changes. Additionally, its caller
is only NativeKey::InitWithKeyChar() and its called with given NativeKey
instance's mModKeyState. So, removing the redundant arguments from
some methods makes them clearer what they compute with.
So, this patch does not change any behavior.
MozReview-Commit-ID: 3w9Ee7PMU05
--HG--
extra : rebase_source : b724a18d5a14672e60ffa5fb9feca5c11dac42a3
By the proposal from Google, <https://github.com/w3c/uievents/issues/147>,
Chromium treat AltRight key as "AltGraph" modifier if the keyboard layout
has AltGr key.
When AltRight key is pressed with a keyboard layout which has AltGr key,
modifiers should as following:
1. "keydown" for ControlLeft:
ctrlKey: true, altKey: false, getModifierState("AltGraph"): false
2. "keydown" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
3. Some "keydown", "keypress" and "keyup" events:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
4. "keyup" for ControlLeft:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
5. "keyup" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): false
So, only when the preceding "keydown" event for ControlLeft, ctrlKey should
be set to true as usual. However, after AltRight key is pressed actually,
we should treat "AltGraph" modifier is true and both ctrlKey and altKey
should be set to false for web apps can handle text input normally.
So, MODIFIER_ALTGRAPH and MODIFIER_CONTROL/MODIFIER_ALT should not be set
at the same time.
This patch makes ModifierKeyState have only MODIFIER_ALTGRAPH or
MODIFIER_CONTROL/MODIFIER_ALT.
Additionally, this patch makes VirtualKey::ShiftState treat "AltGraph" as a
modifier. So, now, VirtualKey needs to convert ShiftState to index value when
it accesses its mShiftStates array. Therefore, this patch adds
VirtualKey::ToIndex() and make each VirtualKey method use it before
accessing mShiftStates.
Note that this patch also fixes bug of WinUtils::SetupKeyModifiersSequence().
The constructor of KeyPair takes 2 keycode values, but the second virtual
keycode can have scancode to distinguish if the key is left or right.
However, WinUtils::SetupKeyModifiersSequence() never sets scancode to
KeyPair. Therefore, it fails to dispatch AltRight key event.
MozReview-Commit-ID: 7ealxJH9KlZ
--HG--
extra : rebase_source : 761bc4416222def020a0731d6ae7940ef074ebe0
For setting AltRight key's key value to "AltGraph" if it should work as so,
we need to know if current keyboard layout has AltGr key. Unfortunately,
Windows doesn't provide such information but we retrieve all input characters
from each key when a keyboard layout is loaded. So, when we load a keyboard
layout, we can mark if current keyboard layout has AltGr key with checking
at least one key inputs different character(s) when AltGr key is pressed.
MozReview-Commit-ID: 8GI3phSVTUS
--HG--
extra : rebase_source : f1622615f03740609984da6d216391e23cae6796
Currently, TSFTextStore::GetTextExt() won't return TS_E_NOLAYOUT error when
ATOK retrieves text rect of all of the composition string.
However, if user converts 2nd or later clause, ATOK retrieves text rect after
start of the character of selected clause. Returning TS_E_NOLAYOUT in this
case causes candidate window being positioned temporarily below first character
of the composition string.
For avoiding the flicker of the candidate window, TSFTextStore::GetTextExt()
shouldn't return TS_E_NOLAYOUT when ATOK retrieves text rects *in* the
composition string.
MozReview-Commit-ID: Cp17HmP2QGK
--HG--
extra : rebase_source : bdd2d2867cccdcf1fe39612ca2f52872d472cb7a
Old ATOK referred native caret position to decide its candidate window position.
However, at least ATOK 2016 does not need to refer it. Additionally, if we
create native caret for ATOK 2016, the candidate window position, ATOK 2016
refers the native caret only when we cannot return expected rect. Therefore,
only immediately after modifying composition string, the position is different
from actual position by a couple of pixels and that looks like flicks the
candidate window.
So, we should stop creating native caret for ATOK 2016 (as same as ATOK 2017).
MozReview-Commit-ID: LsmVXCmRIzc
--HG--
extra : rebase_source : 30b7d15cb23e567b14e1231909aa5a17bdf909a6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
When only a part of window is updated we need to clip that drawing.
We use image surface for that as WindowSurfaceX11Image does.
MozReview-Commit-ID: 13znE1ZszB8
--HG--
extra : rebase_source : a236799fa33d73037913df94c0d5e619c5d3c47e
