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
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
This allows us to have a single const_cast inside GetFramesForArea, and
avoid several callers of these functions (which, as of bug 1556556,
get a const nsIFrame* from RelativeTo inputs) having to const_cast.
Differential Revision: https://phabricator.services.mozilla.com/D70068
It probably doesn't case any problems because the two callers of the function don't hit the case with the bug.
nsLayoutUtils::TransformRootPointToFrame passes nullptr for the ancester frame.
nsIFrame::GetContentOffsetsFromPoint only calls this function if aFrame is in an svg text subtree, so it takes the other branch.
Looks like this was a simple oversight in this change
https://hg.mozilla.org/mozilla-central/rev/204b51a6c6458a30be158a3d1bdca8e9b4edfd67
where TransformRootPointToFrame was changed to TransformAncestorPointToFrame and it originally passed nullptr (which was correct to the Root version fo the function) but didn't get updated in the change.
Differential Revision: https://phabricator.services.mozilla.com/D68954
There are cases when GV is being animated and it ends up being smaller than the
dynamic toolbar for a few frames. When that happens we really don't want to
crash and we can just ignore it.
Differential Revision: https://phabricator.services.mozilla.com/D67364
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
APZ may want to know what the main thread's view of the visual viewport offset
was at the time of the last paint even if the main thread does not want APZ
to scroll to that visual viewport offset.
Differential Revision: https://phabricator.services.mozilla.com/D62093
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
3. Add brackets for the for loop in nsCSSRendering.cpp.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_HALF_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalHalfCorners())"
rename "NS_FOR_CSS_HALF_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalHalfCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61252
Merely checking for having a displayport isn't enough, because the paint to
tell APZ about the new scroll frame could still be pending.
Differential Revision: https://phabricator.services.mozilla.com/D56662
