Bug 1642603 - Make TransformAndClipBounds stop discarding the corner positions of empty rectangles. r=kip, a=RyanVM

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

Bug 1640223 - Expand the given size in ExpandHeightForViewportUnits by multiplying the 'vh value / visible area height'. r=botond

The viewport units size doesn't match the aspect ratio of the screen size in
some cases.

For example, in the case of the reftest in this commit, the meta viewport is
"width=1600, height=device-height" and the screen size during reftest is
"800x1000". Thus the viewport units size will be "1600x1000". In such cases
with the old way ExpandHeightForViewportUnits shrinks the given size
"1600x1800" to "1600x1000" with 100px dynamic toolbar max height (and the
MOZ_ASSERT in the function happens on debug builds).

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

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

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

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

Backed out 3 changesets (bug 1634616) for reftest failures at layout/reftests/transform/partial-prerender-expansion-rotate.html on a CLOSED TREE

Backed out changeset 53da1ae188f4 (bug 1634616)
Backed out changeset 60271de42eb8 (bug 1634616)
Backed out changeset 4279b1647e47 (bug 1634616)

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

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

Bug 1631568 - Have nsLayoutUtils::GetFrameForPoint() and GetFramesForArea() take a RelativeTo parameter. r=tnikkel

This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.

Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.

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

This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.

As part of this change, the types are also moved into namespace mozilla.

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

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

Bug 1556556 - Include the layout-to-visual transform for a zoomed content root in GetTransformMatrix(). r=kats,mattwoodrow

This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.

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

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

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

Bug 1556556 - Add a "relative to layout viewport" option for display list building. r=mstange,mattwoodrow

Use it in document.elementFromPoint().

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

Bug 1215977 added this flag.

Bug 1221870 changed the behaviour of this flag but didn't update the comment.

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

Bug 1633045 - Don't use the Print Preview viewport scroll frame as a scroll container for 'position:sticky' content.  r=TYLin

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

Backed out changeset edd529f7a9c5 (bug 1631568)
Backed out changeset 1cc0881e244b (bug 1631568)
Backed out changeset ed3c1e85d5e3 (bug 1556556)
Backed out changeset 38ffc6215bbf (bug 1556556)
Backed out changeset 03c2c25d8023 (bug 1556556)
Backed out changeset 9c717eb067b8 (bug 1556556)
Backed out changeset 98e26bc98b85 (bug 1556556)
Backed out changeset 05a6a581e755 (bug 1556556)
Backed out changeset 867946cf05bb (bug 1556556)
Backed out changeset 20d72a334530 (bug 1556556)
Backed out changeset 2c62e61d9054 (bug 1556556)
Backed out changeset 62a223d057d2 (bug 1556556)
Backed out changeset 2c5d55a1f0b1 (bug 1556556)
Backed out changeset 700447945b4e (bug 1556556)
Backed out changeset 93190ae4f5ff (bug 1556556)
Backed out changeset a7bd34d961bb (bug 1556556)
Backed out changeset fccd1d3c7189 (bug 1556556)
Backed out changeset 24056e47183d (bug 1556556)
Backed out changeset 204881474cc1 (bug 1556556)
Backed out changeset 387320881876 (bug 1556556)
Backed out changeset be8f5eb58460 (bug 1556556)
Backed out changeset 629c58a9166b (bug 1556556)
Backed out changeset 4312b2b5dda8 (bug 1556556)
Backed out changeset d11dbf6403a5 (bug 1556556)
Backed out changeset 95c54c023779 (bug 1556556)
Backed out changeset 80fcb7e71188 (bug 1556556)
Backed out changeset d75a4ecb0d47 (bug 1556556)
Backed out changeset 903c4de34e7a (bug 1556556)
Backed out changeset f15334a3e803 (bug 1556556)
Backed out changeset 9553e99137ea (bug 1556556)

Bug 1631568 - Have nsLayoutUtils::GetFrameForPoint() and GetFramesForArea() take a RelativeTo parameter. r=tnikkel

This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.

Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.

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

This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.

As part of this change, the types are also moved into namespace mozilla.

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

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

Bug 1556556 - Include the layout-to-visual transform for a zoomed content root in GetTransformMatrix(). r=kats,mattwoodrow

This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.

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

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

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

Bug 1556556 - Add a "relative to layout viewport" option for display list building. r=mstange,mattwoodrow

Use it in document.elementFromPoint().

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

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

This is in anticipation of introducing a struct named RelativeTo
in bug 1556556.

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

--HG--
extra : moz-landing-system : lando

Bug 1623476 - Some const-correctness improvements (nsIFrame* --> const nsIFrame*) in nsLayoutUtils functions. r=tnikkel

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

--HG--
extra : moz-landing-system : lando

Bug 1618345 - Enforce proper color management by splitting gfx::Color into sRGBColor and DeviceColor types. r=jrmuizel

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.service...

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

--HG--
extra : moz-landing-system : lando

Backed out changeset 5005fe56b7b0 (bug 1616715) for failures on test_2_conformance2__canvas__to-data-url-with-pack-params.html. CLOSED TREE

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando

Bug 1601568 - Only send a SetTargetAPZC notification right away if the target has a displayport and it has been painted. r=tnikkel

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

--HG--
extra : moz-landing-system : lando

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

--HG--
extra : moz-landing-system : lando