Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
E.g., comment node is an invisible data node, and it's not handled by
`HTMLEditor` nor `ContentEventHandler`. Therefore, `IMEContentObserver`
should ignore invisible data nodes, which are not derived from `dom::Text`.
Differential Revision: https://phabricator.services.mozilla.com/D107590
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
Unfortunately, it seems that `F7` key handling in `tabbrowser.js` cannot
replaced with using XUL `<key>` element because it works with
`ShortcutUtils.getSystemActionForEvent` for mapping `F7` is a toggle key of
caret browsing mode.
Therefore, this patch exposes some raw information of `WidgetEvent` related
to cross process event propagation and makes `tabbrowser.js` check it and
request reply event if it's required.
So, when a remote content has focus, `tabbrowser.js` will do nothing for both
`keydown` and `keypress` of `F7` key with original events, then, will request
a reply event if its default is not prevented. Finally, reply `F7` keypress
event will toggle caret browsing mode if the event is fired and not consumed.
Differential Revision: https://phabricator.services.mozilla.com/D106591
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
For minimizing the previous patch changes, `scale`'s default value for
`screenX/Y` is treated as 1.0. It means that `screenX/Y` are device
pixels by default, but `offsetX/Y` are in CSS pixels by default. This
difference may make developers confused. Therefore, we should align the
default unit of them to `screenPixelsPerCSSPixel`. I.e., their default
unit becomes CSS pixels.
Differential Revision: https://phabricator.services.mozilla.com/D105929
Some tests want to specify screen position directly. Therefore, they should
have additional fields in the `Object` param to take offset in screen.
Differential Revision: https://phabricator.services.mozilla.com/D105757
In these days, API should take an `Object` instead of multiple arguments
since the callers look like using "named" arguments and this allows to
add new optional arguments with changing not all callers.
This patch also changes similar API for APZ aware tests for keeping
consistent style for their users.
Differential Revision: https://phabricator.services.mozilla.com/D105755
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Simon Giesecke
Jonathan Kew
Masayuki Nakano
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Alexandru Michis
Brindusan Cristian
Butkovits Atila
Andreea Pavel
Micah Tigley
Csoregi Natalia
Sebastian Hengst
Karl Dubost
Tom Schuster
Tim Nguyen
Henri Sivonen
Gerald Squelart
smolnar