Граф коммитов

152 Коммитов

Автор SHA1 Сообщение Дата
kriswright be316b6bf9 Bug 1573992 - Convert 3 ui.key.* prefs to static prefs. r=njn
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.

Differential Revision: https://phabricator.services.mozilla.com/D42392

--HG--
extra : moz-landing-system : lando
2019-08-26 20:25:42 +00:00
Nicholas Nethercote cd426e3ad2 Bug 1569526 - Remove return values from `Add*VarCache()`. r=KrisWright
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)

As a result, the commit removes lots of unnecessary checks.

Differential Revision: https://phabricator.services.mozilla.com/D39804

--HG--
extra : moz-landing-system : lando
2019-07-30 06:19:46 +00:00
Nicholas Nethercote 18fae65f38 Bug 1563139 - Remove StaticPrefs.h. r=glandium
This requires replacing inclusions of it with inclusions of more specific prefs
files.

The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.

Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.

Differential Revision: https://phabricator.services.mozilla.com/D39138

--HG--
extra : moz-landing-system : lando
2019-07-26 01:10:23 +00:00
Nicholas Nethercote cc534d2bb6 Bug 1561825 - Make mousewheel.* static prefs follow the naming convention. r=KrisWright
Differential Revision: https://phabricator.services.mozilla.com/D36161

--HG--
extra : rebase_source : 1466f6cb77029782b391702f5c80f34926995166
2019-06-27 17:14:02 +10:00
Masayuki Nakano 5ac5e497b5 Bug 1555227 - Make GetInternalCommand() return new commands when the command is "cmd_align" without params r=m_kato
`cmd_align` is always with `nsCommandParams` when it's executed.  However,
when somebody checks whether the command is enabled or not, or retrieves the
state, `GetInternalCommand()` is called without `nsCommandParams`.  Therefore,
even when `nsCommandParmas` is nullptr for `cmd_align`, `GetInternalCommand()`
shouldn't warn it.

Additionally, internal command supports to set `align` to empty string.
Therefore, `GetInternalCommand()` also needs to support it.

This patch adds `Command::FormatJustify` for the former case and
`Command::FormatJustifyNone` for the latter case.

Note that this does not affect to actual behavior since `AlignCommand`
does not refer the result of `GetInternalCommand()`.

Differential Revision: https://phabricator.services.mozilla.com/D33604

--HG--
extra : moz-landing-system : lando
2019-06-04 10:01:31 +00:00
Jean-Yves Avenard 04a34db033 Bug 1550422 - P12. Convert Live gfxPrefs into StaticPrefs. r=jrmuizel
gfxPrefs Live preferences are almost identical to StaticPrefs.

We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.

Differential Revision: https://phabricator.services.mozilla.com/D31256

--HG--
extra : moz-landing-system : lando
2019-05-26 14:29:42 +00:00
Gurzau Raul 967bc2a754 Backed out 31 changesets (bug 1552643, bug 1550422) for xpcshell crash on a CLOSED TREE.
Backed out changeset e30c1aa75529 (bug 1552643)
Backed out changeset caadcd7e02d3 (bug 1552643)
Backed out changeset aa7086ab09be (bug 1552643)
Backed out changeset 0b4029671710 (bug 1550422)
Backed out changeset a16295296035 (bug 1550422)
Backed out changeset 3b70307c0db5 (bug 1550422)
Backed out changeset 69df7818d4a3 (bug 1550422)
Backed out changeset d98dfc565927 (bug 1550422)
Backed out changeset 6f0997976944 (bug 1550422)
Backed out changeset 0edd264464c2 (bug 1550422)
Backed out changeset 9ea6da7a74ec (bug 1550422)
Backed out changeset f855f9309c8b (bug 1550422)
Backed out changeset 1033546224a7 (bug 1550422)
Backed out changeset ade7384c6186 (bug 1550422)
Backed out changeset 75b04de7e99c (bug 1550422)
Backed out changeset 91c3acdb2454 (bug 1550422)
Backed out changeset 77d2f80257d1 (bug 1550422)
Backed out changeset e0cd10d35327 (bug 1550422)
Backed out changeset 097091082423 (bug 1550422)
Backed out changeset 2f328853c1ab (bug 1550422)
Backed out changeset f92f2cc29cb1 (bug 1550422)
Backed out changeset 6dc82f88333d (bug 1550422)
Backed out changeset c20f66494d69 (bug 1550422)
Backed out changeset 2ba22cddeb6f (bug 1550422)
Backed out changeset 3aa72f89e295 (bug 1550422)
Backed out changeset ab4c4e806977 (bug 1550422)
Backed out changeset 72e5de040dda (bug 1550422)
Backed out changeset 7d3c2d486706 (bug 1550422)
Backed out changeset 132e0b8d8468 (bug 1550422)
Backed out changeset 54c85ac75dd0 (bug 1550422)
Backed out changeset d7ba4a18dd54 (bug 1550422)
2019-05-25 09:07:49 +03:00
Jean-Yves Avenard af5790cf9b Bug 1550422 - P12. Convert Live gfxPrefs into StaticPrefs. r=jrmuizel
gfxPrefs Live preferences are almost identical to StaticPrefs.

We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.

Differential Revision: https://phabricator.services.mozilla.com/D31256

--HG--
extra : moz-landing-system : lando
2019-05-25 00:03:32 +00:00
Gurzau Raul 74c555539e Backed out 28 changesets (bug 1550422) for marionette AssertionError and failing browser_policy_hardware_acceleration.js on a CLOSED TREE.
Backed out changeset 5dd10a365ba9 (bug 1550422)
Backed out changeset 529f5be01ab9 (bug 1550422)
Backed out changeset b6861d3badf8 (bug 1550422)
Backed out changeset 059cff1a3dde (bug 1550422)
Backed out changeset 6ada1116b241 (bug 1550422)
Backed out changeset ca67e8e45262 (bug 1550422)
Backed out changeset a1961a51ae44 (bug 1550422)
Backed out changeset 1c90b9cb3ad4 (bug 1550422)
Backed out changeset 285fa46e4f26 (bug 1550422)
Backed out changeset e2938a444234 (bug 1550422)
Backed out changeset 7a930fc51125 (bug 1550422)
Backed out changeset 898ed02804fe (bug 1550422)
Backed out changeset e1b7abc99ae9 (bug 1550422)
Backed out changeset f781d415cef6 (bug 1550422)
Backed out changeset 2fef10a7cce5 (bug 1550422)
Backed out changeset ea64b4d8d4ff (bug 1550422)
Backed out changeset 86a8ba1b755c (bug 1550422)
Backed out changeset 9c0c9e80f309 (bug 1550422)
Backed out changeset 10c153ddbaea (bug 1550422)
Backed out changeset 60fe635ec2c9 (bug 1550422)
Backed out changeset a38796266b28 (bug 1550422)
Backed out changeset 2db647dcdf1c (bug 1550422)
Backed out changeset 952ddac02972 (bug 1550422)
Backed out changeset ba46b53643ec (bug 1550422)
Backed out changeset ca47ef6c59f7 (bug 1550422)
Backed out changeset f45f471a1a40 (bug 1550422)
Backed out changeset 371b4da5b771 (bug 1550422)
Backed out changeset 02fc78890032 (bug 1550422)
2019-05-23 05:59:44 +03:00
Jean-Yves Avenard 2c0ce1b3ca Bug 1550422 - P12. Convert Live gfxPrefs into StaticPrefs. r=jrmuizel
gfxPrefs Live preferences are almost identical to StaticPrefs.

We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.

Differential Revision: https://phabricator.services.mozilla.com/D31256

--HG--
extra : moz-landing-system : lando
2019-05-22 12:43:42 +00:00
Masayuki Nakano fc57d9bf0f Bug 1549661 - part 7: Make GetInternalCommand() take nsCommandParams instead of nsAString r=m_kato
`GetInternalCommand()` is currently used only by `EditorCommand` and it
treats the additional parameter only when given command is `cmd_align`.
However, the value is complicated since `AlignCommand` allows both `CString`
value and `String` value.  Therefore, `EditorCommand::DoCommandParams()` may
fail to solve `cmd_align` to a `Command` value without checking both of them.

Therefore, it must make sense that `GetInternalCommand()` take `nsCommandParams`
as optional argument and check it only when given command matches `cmd_align`.
Then, we don't need to waste unnecessary run-time cost.

Note that this bug has been hidden since `AlignCommand` class does not refer
the `Command` value but refers only `nsCommandParams`.  However, the previous
patch makes `EditorCommand::GetParamType()` not allow `Command::DoNothing`.
Therefore, we need this follow-up fix now.

Differential Revision: https://phabricator.services.mozilla.com/D30501

--HG--
extra : moz-landing-system : lando
2019-05-21 07:47:51 +00:00
Masayuki Nakano a658371e04 Bug 1546839 - part 3: Create methods which retrieve `Command` value for XUL command name r=smaug
Now, we don't have any utility method to get `Command` value for XUL command
name.  This patch creates it into `mozilla` namespace.

Differential Revision: https://phabricator.services.mozilla.com/D29173

--HG--
extra : moz-landing-system : lando
2019-04-30 04:24:26 +00:00
Masayuki Nakano b469ceda1d Bug 1546839 - part 2: Define commands which are handled by editor r=smaug
`NS_DEFINE_COMMAND_WITH_PARAM` macro is special case for `cmd_align`.
`cmd_align` can be mapped to multiple `Command` values.  It's distinguished
with additional parameter, '"left"', '"right"', '"center"' or '"justify"'.
Therefore, we cannot map from XUL command to `Command` value simply with
hashtable created by the next patch.  So, this new macro is necessary for
the next patch to ignore this special case.

The used commands are listed up from:
* [converted from `execCommand`, `cmd_bold` - `cmd_superscript`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2066-2071)
* [converted from `execCommand`, `cmd_undo` - `cmd_redo`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2078-2079)
* [converted from `execCommand`, `cmd_paragraphState` - `cmd_outdent`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2080-2081,2105-2106)
* [converted from `execCommand`, `cmd_align`s](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2095-2098)
* [converted from `execCommand`, `cmd_highlight` - `cmd_decreaseFont`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2082-2088)
* [converted from `execCommand`, `cmd_insertHR` - `cmd_ul`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2089-2093,2101-2102)
* [converted from `execCommand`, `cmd_getContents` - `cmd_enableAbsolutePositionEditing`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/dom/html/nsHTMLDocument.cpp#2094,2099-2100,2107-2113)
* [internal commands, `obs_documentCreated` - `obs_documentWillBeDestroyed`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#26-28)
* [internal command, `cmd_abbr`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#68)
* [internal command, `cmd_absPos`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#102)
* [internal commands, `cmd_acronym` - `cmd_var`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#58,63,65-67,69-72)
* [internal commands, `cmd_dd` - `cmd_dt`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#78-79)
* [internal commands, `cmd_moveDown` - `cmd_selectUp2`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/EditorController.cpp#97-112)
* [internal command, `cmd_setDocumentModified`](https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/editor/libeditor/HTMLEditorController.cpp#31)

Differential Revision: https://phabricator.services.mozilla.com/D29171

--HG--
extra : moz-landing-system : lando
2019-04-30 06:04:01 +00:00
Masayuki Nakano 6c0c323d6f Bug 1546839 - part 1: Change `enum Command` to `enum class Command` and drop "Command" prefix from each item r=smaug
If I remember correctly, `enum class` was not allowed when I added
`enum Command`.  Now, we can make it `enum class` for better type check at
compile time.

Differential Revision: https://phabricator.services.mozilla.com/D29169

--HG--
extra : moz-landing-system : lando
2019-04-30 04:23:24 +00:00
Ryan Hunt 63c8e0660c Bug 1523969 part 26 - Move method definition inline comments to new line in 'widget/'. r=mstange
Differential Revision: https://phabricator.services.mozilla.com/D21130

--HG--
extra : rebase_source : 83867879cf33ddd2cc1b19c20dff8cef6a51d1a9
extra : histedit_source : 67979b7a263223c1e48421f382ed1e78d6264cf9
2019-02-25 16:13:48 -06:00
Masayuki Nakano ed2040ac16 Bug 1447239 - Implement InputEvent.inputType r=smaug
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
2019-01-07 10:10:57 +00:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Tim Huang a8de9d009f Bug 1363508 - Part 2: Suppressing the pointer events that have isPrimary as false for fingerprinting resistance r=arthuredelstein,masayuki
Because of that the isPrimary of mouse pointer events will always be
true. So, we suppress other events that have isPrimary as false when
fingerprinting resistance is enabled.

Depends on D6003

Differential Revision: https://phabricator.services.mozilla.com/D6004

--HG--
extra : moz-landing-system : lando
2018-10-09 11:50:01 +00:00
Masayuki Nakano fd4e78f2a1 Bug 1461708 - part 5: Move EditorEventListener::HandleMiddleClickPaste() to EventStateManager r=smaug
EventStateManager needs to handle middle click paste without editor.
Therefore, the handler should be in EventStateManager.

Differential Revision: https://phabricator.services.mozilla.com/D7852

--HG--
extra : moz-landing-system : lando
2018-10-10 12:04:17 +00:00
Masayuki Nakano eb2efb612f Bug 1343955 - part 2: Implement _guessCodeFromKeyName() in EventUtils.js with C++ and make it accessible with nsITextInputProcessor for EventUtils.js r=smaug
We need to port synthesizeKey() of EventUtils.js to FuzzingFunctions.  So,
its helper function, _guessCodeFromKeyName() in EventUtils.js needs to be
accessible from FuzzingFunctions.  Therefore, we need to reimplement it
with C++ and make it accessible via nsITextInputProcessor for EventUtils.js
for making easier to maintain.

This patch moves _guessCodeFromKeyName() into TextInputProcessor and
WidgetKeyboardEvent.  Non-printable key part of _guessCodeFromKeyName() is
moved to WidgetKeyboardEvent::ComputeCodeNameIndexFromKeyNameIndex() because
of not depending on active keyboard layout.  On the other hand, printable
key part needs to assume that active keyboard layout is en-US keyboard layout.
Therefore, it's moved to
TextInputProcessor::GuessCodeValueOfPrintableKeyInUSEnglishKeyboardLayout()
because any Core code shouldn't refer it as utility method for keeping that
we're i18n-aware.

Differential Revision: https://phabricator.services.mozilla.com/D5514

--HG--
extra : moz-landing-system : lando
2018-10-03 09:21:47 +00:00
Jeff Gilbert 5b753da289 Bug 1470325 - s/FooBinding/Foo_Binding/g - r=qdot
MozReview-Commit-ID: JtTcLL5OPF0
2018-06-26 17:05:01 -07:00
Boris Zbarsky 597b4545d2 Bug 1429903 part 4. Remove nsIDOMEventTarget. r=mccr8
MozReview-Commit-ID: 9XuenUHxfPx
2018-04-20 00:49:30 -04:00
Boris Zbarsky adbcff27c1 Bug 1449631 part 7. Remove nsIDOMEventTarget::GetTargetFor* methods. r=smaug
MozReview-Commit-ID: AIzDo67mTDf
2018-04-05 13:42:41 -04:00
Olli Pettay 9e35535e7d bug 1447196, canceling pointerdown should not affect to scrollbar handling, r=masayuki
--HG--
extra : rebase_source : a84d2a393d82dcc7655e9bb48a118ddd300c3d4e
2018-03-23 17:31:13 +02:00
Margareta Eliza Balazs 9ecc515945 Backed out changeset b4f1e88f8b6e (bug 1447196) for 2 failures in dom/events/test/pointerevents/test_bug1303704.html 2018-03-23 05:37:20 +02:00
Olli Pettay 8d1253d263 bug 1447196, canceling pointerdown should not affect to scrollbar handling, r=masayuki
--HG--
extra : rebase_source : 3234983256e2d68e0ac6b21f5293b23bf6017b11
2018-03-22 20:54:50 +02:00
Andreea Pavel 12274151d8 Backed out changeset 36c52265e4a1 (bug 1447196) for mochitest headless failures at dom/events/test/pointerevents/test_bug1303704.html on a CLOSED TREE 2018-03-22 18:44:37 +02:00
Olli Pettay d660f15a38 bug 1447196, canceling pointerdown should not affect to scrollbar handling, r=masayuki
--HG--
extra : rebase_source : 148a87834ef2baf41c2889bfed1b78bc42ec5e2b
2018-03-22 15:53:55 +02:00
Masayuki Nakano 1c1a60c08d Bug 1446253 - Make EventUtils.synthesizeComposition() dispatch keydown and keyup event in default r=smaug
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
2018-03-16 22:35:07 +09:00
Masayuki Nakano ed18f14624 Bug 1036008 - Use alternative ASCII capable keyboard layout information to decide keyCode even if the key produces an ASCII punctuation character r=smaug
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
2018-02-16 15:54:07 +09:00
Boris Zbarsky 92bbd744e1 Bug 1436508 part 11. Remove the use of the nsIDOMKeyEvent::DOM_VK* constants in C++. r=masayuki
MozReview-Commit-ID: Honw0NrVMuV
2018-02-09 11:17:09 -05:00
Tim Huang 98af9c6f96 Bug 1222285 - Part 2: Making the keyboard events of modifier keys been suppressed when 'privacy.resistFingerprinting' is true. r=arthuredelstein,masayuki
This patch makes 'Shift', 'Alt', 'Contorl' and 'AltGraph' been suppressed for content
when fingerprinting resistance is enabled. Chrome can still get these events.

The reason behind this is that websites can still observe key combinations to
tell which keyboard layout is using even we spoof the keyboardEvent.code,
keyboardEvent.keyCode and modifier states. For example, the AZERTY France
keyboard, the digit keys of it requires the user press the Shift key. So, it is
easy to differentiate AZERTY and QWERTY keyboard by observing whether a Shift key
generates its own before the digit keys. There are similar issues for 'Alt' and
'AltGraph' as well.

MozReview-Commit-ID: 3CwCgvey4lK

--HG--
extra : rebase_source : 225a34ab188f6cca288a6c0e9874261df7db629f
2017-08-31 11:14:14 +08:00
Masayuki Nakano af6a1c5d37 Bug 1403759 - part 2: Handle edit/selection commands like insertNewline: in TextInputHandler::HandleCommand() r=m_kato
Let's make TextInputHandler::HandleCommand() handle other
commands which are caused by Backspace, Delete, Tab, ArrowUp,
ArrowDown, ArrowRight, ArrowLeft, PageUp, PageDown, Home, End
and Escape keys with various modifiers.

This patch makes Korean users can do most key operation in
editor even with composing Hangul character.

Note that this patch has a hack for cancelOperation: command.
The command is typically fired for Escape key press.  However,
it's also fired for Command + Period.  Unfortunately, this
behavior is really odd if subclass of NSResponder implements
|void cancelOperation:(id)sender|.  If it's implemented,
Cocoa doesn't call its |void keyDown:(NSEvent)theEvent|.
Instead, it calls only |void doCommandBySelector:(SEL)aSelector|
and |void cancelOperation:(id)sender| when Command + Period is
pressed.  Therefore, we cannot dispatch keydown nor keypress
event for this key combination if we implement it.  Therefore,
this patch doesn't implement the method but handle it in
doCommandBySelector even though the super class of ChildView
cannot handle the command with this path.

MozReview-Commit-ID: 4hS23SiwNJv

--HG--
extra : rebase_source : 38ac1ea494b5f786ecd5c9327efbacd460b59faf
2017-12-02 14:53:10 +09:00
Masayuki Nakano d7ecd695d3 Bug 1403759 - part 1: Make TextInputHandler::InsertNewline() treat other commands r=m_kato
Currently, we handle insertNewline: of NSResponder with
TextInputHandler::InsertNewline().  However, its
implementation is useful for handling some other
commands.  So, let's rename it to HandleCommand() and
make it take Command as its argument for handling
specific behavior of each command.

MozReview-Commit-ID: GgzQdTlVtYl

--HG--
extra : rebase_source : e1d1c8617897d29eb10ba62708e3549a77c6ee59
2017-12-02 10:46:31 +09:00
James Willcox bacda12532 Bug 1409113 - Add nsIPresShell::HasHandledUserInput() r=masayuki
MozReview-Commit-ID: 3Yr5UmFJx5h
2017-11-22 10:09:04 -06:00
Neil Deakin 4b1d934d48 Bug 1411705, check the pseudo char code in GetAccessKeyCandidates so that this check works in both keydown and keypress events, r=masayuki 2017-11-09 18:42:40 -05:00
Masayuki Nakano 93977460e2 Bug 1406446 - part 1: InputContextAction should treat focus change during handling a user input as caused by user input even if it's caused by JS r=smaug
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB.  For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.

Therefore, InputContextAction should declare two causes.  One is unknown but
occurred during handling non-keyboard event.  The other is unknown but occurred
during handling keyboard event.

However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event.  Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling.  Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.

IMEStateManager uses this new API to adjust the cause of changes of input
context.

Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.

MozReview-Commit-ID: 5JsLqdqeGah

--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
2017-10-24 02:46:15 +09:00
Stone Shih 6cbc21aa58 Bug 1355497: Ignore preventDefault on pointerdown by WebExtensions. r=smaug.
Prevent default on pointerdown will stop firing the subsequent mouse events. Ignore the case that preventDefault by WebExtensions to avoid breaking some websites.

MozReview-Commit-ID: 9ztW1WfEg9a
2017-07-10 16:42:01 +08:00
Masayuki Nakano 0ebdc75b7b Bug 1333459 - part2-3: Make nsMenuBarListener::KeyPress() wait reply from remote process if the eKeyPress event will be sent to a remote process later r=smaug
nsMenuBarListener::KeyPress() is eKeyEvent listener in the system event group.  If the target is a remote process, it shouldn't handle accesskey immediately because preceding eKeyDown event may be consumed in the remote process or eKeyPress event itself may be consumed in the remote process.

This patch makes nsMenuBarListener::KeyPress() mark eKeyPress event as "waiting reply from remote process" only when the event matches with a menu item's accesskey and it will be send to a remote process later.  Then, reply event should be handled in this method if it's available.

MozReview-Commit-ID: KOpCVgElnca

--HG--
extra : rebase_source : 881ec01f5c8e21c790bf9a8c3167d6c3f932524a
2017-07-19 18:39:34 +09:00
Masayuki Nakano 6c68caecd7 Bug 1333459 - part1: Move methods of EventStateManager which check modifiers of access key to WidgetKeyboardEvent r=smaug
EventStateManager checks if every keypress event's modifiers match with access key modifiers which are in prefs. Moving related methods of this to WidgetKeyboardEvent makes EventStateManager simpler and we can hide the NS_MODIFIER_* constants (they may make developers confused between Modifiers of WidgetInputEvent) into WidgetEventImpl.cpp.

MozReview-Commit-ID: 23NUQ51lJ1M

--HG--
extra : rebase_source : 341f3764ef62575577572d8b349159e2d5512b26
2017-07-06 17:36:19 +09:00
Sylvestre Ledru 7c0ae251cd Bug 1381253 - Remove redundant control flow declarations rs=ehsan
MozReview-Commit-ID: FFxP4aMCbOL

--HG--
extra : amend_source : 3aec108430b11048f47ffe19d5da7ac5034770a9
2017-07-15 19:03:04 +02:00
Masayuki Nakano 57f359b0de Bug 1377653 - part2: Add helper methods to WidgetEvent and BaseEventFlags to manage propagation state between parent process and remote process r=smaug
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process.  However, it's really complicated.  Actually, setting these flags and referring the flags is usually follow explanation.

So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.

This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome.  That allows us to manage the cross process event propagation state in same place.

MozReview-Commit-ID: IXEDQJ4GpAZ

--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
2017-07-05 13:58:41 +09:00
Ryan Hunt e747db20e3 Bug 1351783 part 2 - Add a KeyboardInput type. r=kats
Every event type handled by APZ needs to have a InputData type. This commit
adds a new KeyboardInput type that stores the minimum fields needed to match
keyboard shortcuts.

MozReview-Commit-ID: 3KUnH4sWrST

--HG--
extra : rebase_source : 710274199a1ced0716abe02e9d6aaea0d31c9498
2017-06-05 18:09:40 -05:00
Masayuki Nakano 85a1d561a2 Bug 1339543 part 6 PBrowser::RequestNativeKeyBindings() should retrieves edit commands only for specified type r=smaug
PBrowser::RequestNativeKeyBindings() is used only when somebody tries to
execute native key bindings for synthesized keyboard events.  Therefore, it
doesn't need to retrieve edit commands for all editor types.  Instead, it
should take the editor type and just return the edit commands for it.

MozReview-Commit-ID: HF4Gz99SBQP

--HG--
extra : rebase_source : e332d2ef5ae36949a9a362d8f95c5d427c9812e7
2017-05-19 18:46:02 +09:00
Masayuki Nakano 872f694c63 Bug 1339543 part 4 Change nsIWidget::ExecuteNativeKeyBinding() to nsIWidget::GetEditCommands() which just retrieves edit commands for the type r=smaug
Now, nsIWidget::ExecuteNativeKeyBinding() isn't used by anybody for executing
edit commands.  Instead, they need array of edit commands for the key
combination.  So, the method should be renamed to GetEditCommands() and just
return edit commands as an array.

MozReview-Commit-ID: 4G0B1lJ8Lbe

--HG--
extra : rebase_source : 4a5829281d59677c773950c34d91a1cd8074d243
2017-05-19 17:49:41 +09:00
Masayuki Nakano 730193bdb6 Bug 1339543 part 2 eKeyPress event should have edit commands for all editor types when it's dispatched to a remote process r=smaug
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types.  Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.

Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab.  However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too.  (And the test has a bug.  It tries to wait 0.5
sec when every keydown or keypress event.  However, it fails since startTime
is never initialized.  This patch fixes this bug too.)

MozReview-Commit-ID: IYhyxqH3Ch8

--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
2017-05-19 17:24:20 +09:00
Masayuki Nakano 6d8d004613 Bug 1339543 part 1 Wrap nsIWidget::ExecuteNativeKeyBinding() with a WidgetKeyboardEvent method and users of the method should use it r=smaug
Currently, edit commands for native key bindings are stored in widget.  This is
stateful and really complicated in content process because it needs to cache
them.

We can make this simpler if we make WidgetKeyboardEvent store edit commands for
the key combination.  Then, child process can handle it even if it's delayed
event or it's a nested event.

This patch adds arrays to WidgetKeyboardEvent to store edit commands which are
initialized with nsIWidget::ExecuteNativeKeyBinding() and adds
WidgetKeyboardEvent::ExecuteEditCommands() to execute stored edit commands as
same as nsIWidget::ExecutenativeKeyBinding().

MozReview-Commit-ID: BGRvBrLz5lp

--HG--
extra : rebase_source : b7ecd704d9c331ca1e0aedc66f230114015b853b
2017-05-19 16:50:30 +09:00
Stone Shih f3b56f1a20 Bug 1340085 - [Pointer Event] Stop firing pointer events after firing eTouchCancel. f=smaug. r=kats
--HG--
extra : rebase_source : 95539f13dd0316cb4c01382a4c0213b00dcb64b0
2017-02-16 15:05:09 +08:00
Masayuki Nakano 5442d350f3 Bug 1337739 Create an enum eKeyLocation* for avoiding to use nsIDOMKeyEvent::DOM_KEY_LOCATION_* r=smaug
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode.  Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*.  Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.

MozReview-Commit-ID: 5cs4zQ061Lc

--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
2017-02-08 21:04:22 +09:00
Masayuki Nakano 7ab96b2cef Bug 1314053 part.2 Change EditorBase::IsAcceptableInputEvent()'s argument from nsIDOMEvent* to WidgetGUIEvent* r=smaug
MozReview-Commit-ID: Jo6EwQubUAM

--HG--
extra : rebase_source : 098b23946f349bbe7641a2059538ffb20ae4f5bb
2017-01-17 17:17:06 +09:00