***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This prevents mouse events from firing on browsers in unfocused windows. It used to be done
with the [clickthrough=never] attribute set from XBL content.
Differential Revision: https://phabricator.services.mozilla.com/D16498
--HG--
extra : moz-landing-system : lando
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The usage of our specific "text" event is enough low (0.0003%). So, let's
stop dispatching the event in the default group of web content. Once we
release this new behavior, we can get rid of dispatching the event even in
chrome. Then, we can optimize the event order for new specs.
Differential Revision: https://phabricator.services.mozilla.com/D13034
--HG--
extra : moz-landing-system : lando
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
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
- Count open file descriptors instead of testing the existence of a file
(because the clipboard is now only reachable through file descriptors,
and not through a file path).
- Use a fixed string instead of a random string. The previous way of
generating a string was non-deterministic, and there was a very small
chance that the generated string was not large enough to trigger the
cache-to-disk-mode.
- Use "text/unicode" instead of "text/plain", because JavaScript strings
use two bytes, not one bytes each.
- The cache file is already created when the Transferable is created, so
check the cache file after assigning data to the nsITransferable, but
before copying it to the clipboard.
MozReview-Commit-ID: KOkYOm280Oh
--HG--
extra : rebase_source : 3515ff55a316720b87f2473a1450e5d8304728e8
This a remaining issue of bug 1435180. We need to skip keypress event check of
non-printable key operation in the test.
MozReview-Commit-ID: InobZCbrzWL
--HG--
extra : rebase_source : 9f17cd04500f4ef31c3674087188ec6ee157173b
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
We shouldn't assume it's safe to write to /tmp unless we know
for sure we are not in a private browsing window. So
use mPrivateData = true as default.
Based on a patch by Neill Miller:
https://trac.torproject.org/projects/tor/ticket/21830
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Kris Maglione
Ehsan Akhgari
Emilio Cobos Álvarez
Brian Grinstead
Masayuki Nakano
Sylvestre Ledru
Mark Banner
Ciure Andrei
Tom Schuster
Csoregi Natalia
Jonathan Kingston
Gurzau Raul
Xidorn Quan
Dorel Luca
Chris Peterson
Hiroyuki Ikezoe
Geoff Brown
Boris Zbarsky
Narcis Beleuzu
Joel Maher
Noemi Erli
Stefan Hindli
Dale Harvey
Neil Deakin
Timothy Guan-tin Chien
Zhang Junzhi
Tim Nguyen
Margareta Eliza Balazs
Andreea Pavel
Valentin Gosu
Cosmin Sabou
Rob Wu
Florian Quèze
Arthur Edelstein
Andrew McCreight
Brindusan Cristian
Stone Shih