This patch covers thw low-hanging fruit: headers that either don't use
nsLayoutUtils.h at all, or where only method implementations that can
easily be moved to the .cpp file use it.
Differential Revision: https://phabricator.services.mozilla.com/D91504
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
Instead of just special-casing the eContextMenu and eMouseLongTap events in
PositionedEventTargeting, this adds a mechanism to suppress retargeting for
any events dispatched from a particular code block. This allows us to also
suppress retargeting the mousemove that precedes the eContextMenu, while still
retargeting any other mousemove events (e.g. the one that precedes a click).
Doing this is important because if the mousemove is retargeted, it can trigger
the hover pseudoclass CSS on an element when that element is not actually
going to be activated at all, and can be confusing to the user.
Depends on D65211
Differential Revision: https://phabricator.services.mozilla.com/D65212
--HG--
extra : moz-landing-system : lando
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
The PositionedEventTargeting code allows input events to be dispatched to a
target not directly under the input event point. However, the coordinates of the
input event can then end up outside the bounding rect of the event target. This
state is generally unexpected by web content and may cause compatibility issues.
Fennec's front-end code used to deal with this by repositioning the input event
coordinates to be inside the bounding rect; now that Fennec is using the shared
C++ code we need to have that code here. This behaviour is guarded by a pref and
disabled by default (but enabled on Fennec).