DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
TextEditor modifies composition string or selected string when first
eCompositionChange event is received. However, TextComposition dispatches
eCompositionChange event ("text" event of DOM) only when composition string
becomes non-empty if current composition string is empty. So, when IME
dispatches only eCompositionStart and eCompositionCommit events for removing
selected text, TextEditor does nothing. This hacky behavior is used by
MS Pinyin on Windows 10 at least.
For supporting this behavior, we need to make TextComposition dispatch
eCompositionChange event when eCompositionChange(AsIs) event is fired
even before dispatching eCompositionChange event.
Although from point of view of web apps, the hacky composition should be
merged into the previous composition if it's possible but it's out of scope
of this bug.
MozReview-Commit-ID: 7QfeBJamGTU
--HG--
extra : rebase_source : 8de1353021f2961ae9f8bdf17ddded1058175339
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
|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
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
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
On macOS, option key is mapped to alt key, and it works like AltGr key on
the other platforms. Since our editor doesn't accept keypress events as
typing printable character if one of altKey, ctrlKey and metaKey of the
events is true, widget for macOS sets those attributes to false when an
editor has focus. On the other hand, if no editor has focus, our widget
does not do this hack so that altKey and ctrlKey values of keypress events
are always same as actual user operation and this is same behavior as the
other browsers. Therefore, we need to keep setting altKey of keypress
events to true if no editor has focus but we need to dispatch keypress
events even on content unless the charCode is 0.
So, only on macOS, WidgetKeyboardEvent::IsInputtingText() does not need
to check altKey state.
MozReview-Commit-ID: 4DMgdOfLqvQ
--HG--
extra : rebase_source : 18db91c0d77c6910a206e6c767e6f3b5cfd1c2ab
nsScrollbarFrame::CreateAnonymousContent() would create the children
markup originally created by XBL. The attributes updated by XBL attribute
inheritance is updated by nsScrollbarFrame::UpdateChildrenAttributeValue().
This removes the XBL part of the scrollbar implementation.
MozReview-Commit-ID: FWi3HR2qkwF
--HG--
extra : rebase_source : c0b1b2ddbccb1d8e9d523db91a5b81fbcfa328e9
Some mochitests are not meant to test default actions for wheel events, but they
assume audo-dir is disabled when doing tests for their purposes, so this commit
disables auto-dir for those mochitests.
MozReview-Commit-ID: 5ZQIxgRVpj5
--HG--
extra : rebase_source : a185a2f65179ec9162ec04209b4eb29e8c04125b
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
* Deserialization now only happens via a mutator
* The CID for URI implementations actually returns the nsIURIMutator for each class
* The QueryInterface of mutators implementing nsISerializable will now act as a finalizer if passed the IID of an interface implemented by the URI it holds
MozReview-Commit-ID: H5MUJOEkpia
--HG--
extra : rebase_source : 01c8d16f7d31977eda6ca061e7889cedbf6940c2
On Windows, VK_PROCESSKEY key message is sent if the key event is handled by
IME (in IMM mode or IMM-IME). Therefore, we can set
WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and
WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when
we receive VK_PROCESSKEY.
MozReview-Commit-ID: 9B8Q7rwfXYD
--HG--
extra : rebase_source : f1ed228b295e6c4bd41192bc773b8118a28db6bc
On Windows, VK_PROCESSKEY key message is sent if the key event is handled by
IME (in IMM mode or IMM-IME). Therefore, we can set
WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and
WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when
we receive VK_PROCESSKEY.
MozReview-Commit-ID: 9B8Q7rwfXYD
--HG--
extra : rebase_source : a15105e3b6acf1f1911a8299911353dc4179e2c0
I accidentally broke the ability to retrieve a big string from the
clipboard, and there was no test that failed. So this provides a new
test that does the following:
1. Store a big string in a nsTransferable.
2. Copy it to the clipboard.
3. Create a new nsTransferable, initialize with small data.
4. Populate the nsTransferable with (big) data from the clipboard.
5. Populate the nsTransferable with small data.
After each step, the test checks whether the transferable holds the
expected data and length, and (on non-Windows) checks that the big
data is backed by a file, and small data is not.
MozReview-Commit-ID: 9yuXZxVqD6R
--HG--
extra : rebase_source : 6cec638c59e8ce5a18adbb642779c1dcd457cc5b
Geoff Brown
Boris Zbarsky
Kris Maglione
Narcis Beleuzu
Masayuki Nakano
Brian Grinstead
Xidorn Quan
Joel Maher
Noemi Erli
Stefan Hindli
Mark Banner
Dale Harvey
Neil Deakin
Timothy Guan-tin Chien
Zhang Junzhi
Tim Nguyen
Margareta Eliza Balazs
Andreea Pavel
Valentin Gosu
Cosmin Sabou
Rob Wu