Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
I would like to log `IMEState` and `InputContextAction`in widget. But this
utilities are in `IMEStateManager`, so I would like to move it to widget
by using `mozilla/ToString.h`.
Differential Revision: https://phabricator.services.mozilla.com/D44103
--HG--
extra : moz-landing-system : lando
Converted the following to StaticPrefs so that we can easily test variations:
NS_GC_DELAY
NS_SHRINK_GC_BUFFERS_DELAY
NS_FIRST_GC_DELAY
NS_FULL_GC_DELAY
NS_INTERSLICE_GC_DELAY
NS_USER_INTERACTION_INTERVAL
Differential Revision: https://phabricator.services.mozilla.com/D43112
--HG--
extra : moz-landing-system : lando
As Chrome and Safari didn't block autoplay when haiving user input on editable content, it causes a compatible issue on Firefox because we only allow user inputs happening on non-editable content to activate document.
It seems that we don't really need to restrict that user inputs, which can activate document, should only occur on non-editable content.
Even if they occur on non-editable content, it might still have a chance to annoy user, it's totally depending on websites' design.
Differential Revision: https://phabricator.services.mozilla.com/D43532
--HG--
extra : moz-landing-system : lando
When contents notify IME or requests something to IME, they need to use
an `nsIWidget` instance which may have focus if active, and handles
native keyboard/IME events since that knows correct native IME context.
Currently, such widget exactly matches with the result of
`nsPresContext::GetRootWidget()`. However, this is unclear for most developers.
Therefore, this patch creates a wrapper method of it named
`nsPresContext::GetTextInputHandlingWidget()`. Then, also adds
`BrowserParent::GetTextInputHandlingWidget()` wraps it. Finally, makes
`IMEStateManager` call `GetTextInputHandlingWidget()` of them.
Differential Revision: https://phabricator.services.mozilla.com/D42301
--HG--
extra : moz-landing-system : lando
All of these prefs are already static prefs, so this removes the varcache pref definitions from WheelTransaction and replaces them with the existing static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D42040
--HG--
extra : moz-landing-system : lando
Converts zoom.maxPercent and zoom.minPercent to static prefs, which creates a new "zoom" category on StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41835
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
We check surrogate pair at specific index in `nsTextFragement` in a lot of
places. This requires boundary check of the index so that it can cause
security issue and crash reason with simple mistake, and also it steals
your time to understand the code what it does especially when it's a
part of an `if` condition.
Therefore, this patch adds new API to `nsTextFragment` and makes the all
surrogate pair handlers of `nsTextFragument` use new API.
Differential Revision: https://phabricator.services.mozilla.com/D39689
--HG--
extra : moz-landing-system : lando
`IMEContentObserver` treats `<br>` elements as linefeed, but ignores padding
`<br>` elements. Padding `<br>` element for last empty line was inserted as
normal `<br>` element and then, its attribute was set by editor. Therefore,
`IMEContentObserver` needed to observe attribute changes. However, editor
stops using attribute to mark as padding and stops inserting as normal `<br>`
element first (i.e., inserting `<br>` after setting its flag). Therefore,
`IMEContentObserver` does not need to observe attribute changes anymore.
Differential Revision: https://phabricator.services.mozilla.com/D39861
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element to end of a block if last line
of the block is empty because caret should be placed as there is an empty
line. Such special `<br>` element has `type` attribute whose value is "_moz".
However, adding/removing the attribute is expensive and such hacky attribute
shouldn't be referred nor changed by web apps.
Therefore, this patch makes `HTMLBRElement` take another specific flag whether
it's a special node for empty last line. For making the meaning clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty last line" insead of "moz-br". So, this patch also includes a lot of
renaming methods and variables, and modifying related comments.
Note that with this change, `IMEContentObserver` counts the padding `<br>`
element in `<textarea>` because it's inserted before setting the new flag
and setting the flag does not cause DOM tree mutation. This issue will be
fixed by the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D39858
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
This was an oversight in bug 1520154. We kept the -moz- version in the specified
value but not the computed value.
That's a very peculiar way of making aliases work. This makes them work
consistently as many other aliases instead.
Also, add an assert that would've caught this much much earlier.
Differential Revision: https://phabricator.services.mozilla.com/D40063
--HG--
extra : moz-landing-system : lando
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
If copying selected password is allowed by `TextEditor`, we should allow to
drag it too because web apps usually request to input new password twice,
but if users used password generator, they may want to use drag and drop the
new password rather than copy and paste.
Differential Revision: https://phabricator.services.mozilla.com/D39279
--HG--
extra : moz-landing-system : lando
First, we need to make `nsCopySupport::FireClipboardEvent()` keep handling
`eCopy` and `eCut` event even in password field, only if `TextEditor` allows
them.
Then, we need to make `nsPlainTextSerializer::AppendText()` not expose
masked password for making users safer. Although `TextEditor` does not allow
`eCopy` nor `eCut` when selection is not in unmasked range. Fortunately,
retrieving masked and unmasked password from `nsTextFragment` has already
been implemented in `ContentEventHandler.cpp`. This patch moves it into
`EditorUtils` and makes `ContentEventHandler.cpp` and `nsPlaintextSerializer`
share it.
Differential Revision: https://phabricator.services.mozilla.com/D39000
--HG--
extra : moz-landing-system : lando
Some failures crept in and out after my last sets of annotations landed. This
patch updates most of the annotations to deal with them.
MANUAL PUSH: Lando won't let me land.
Differential Revision: https://phabricator.services.mozilla.com/D39462
--HG--
extra : rebase_source : 4cfccf95c5bb2521533a9f5c4c25d67f414fb6f5
extra : histedit_source : c19187a3b3002e0eebdd809738b57641e1e432cd
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
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
This is what other browsers do, and it does make sense to me, it's useless to
try to scroll a frame with no scroll range in a given direction.
I think all callers of this function should be treated like this, so this is
more like a RFC / feedback request than a patch per se.
The wheel handling code already checks scroll range, so there's no difference of
behavior in that case, if I'm reading the code right.
There are a few other functions that check the result of
GetPerceivedScrollingDirections(), but I think if we change this we should
change this consistently.
I also think that if we do this we should rename the method to something like
GetAvailableScrollingDirections() or such.
Anyhow, wdyt? I should also add a test for this if we go with this.
Differential Revision: https://phabricator.services.mozilla.com/D38991
--HG--
extra : moz-landing-system : lando
Unmasking is an optional style of showing password. Therefore, if callers of
`nsIEditor::Unmask()` specify middle of surrogate pair(s), it may mean that
they want to expand the unmask range from shorter range which does not include
the high and/or low surrogate. Therefore, one of the surrogates is in unmasked
range, we unmask the surrogate pair. However, we handle this in a lot of
places, i..e., we have duplicated code. This can get rid of these duplicates
with making `nsIEditor::Unmask()` expand the range automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38432
--HG--
extra : moz-landing-system : lando
In some cases, other tools may show selected content in their UI. E.g.,
character palette of macOS. Therefore, we shouldn't allow them to show
masked password.
Differential Revision: https://phabricator.services.mozilla.com/D38430
--HG--
extra : moz-landing-system : lando
Now, the anonymous text node has raw value of password so that we shouldn't
allow users to drag the text since another user may have typed the password
and left from the device.
Note that we've supported the operation, however, it does not make sense
since the dragging data is masked text.
Additionally, Chrome also doesn't support dragging text in password fields.
So, we have no reason to support dragging raw value from password fields.
Differential Revision: https://phabricator.services.mozilla.com/D38012
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
John Dai
Razvan Maries
Dave Townsend
Emilio Cobos Álvarez
Gerald Squelart
Mark Banner
Makoto Kato
Andrew Creskey
alwu
Logan Smyth
Sylvestre Ledru
Sebastian Streich
Masayuki Nakano
Olli Pettay
Daniel Varga
Brindusan Cristian
Kristen Wright
Brendan Dahl
Nicholas Nethercote
longsonr
Bogdan Tara
Kannan Vijayan
Kris Maglione
Coroiu Cristina
Narcis Beleuzu
Boris Zbarsky
Ciure Andrei