Bug 1631568 - Move ViewportType and RelativeTo into a separate header…

…. r=tnikkel

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

layout/base/RelativeTo.h

@@ -0,0 +1,51 @@
+/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
+/* vim: set ts=8 sts=2 et sw=2 tw=80: */
+/* This Source Code Form is subject to the terms of the Mozilla Public
+ * License, v. 2.0. If a copy of the MPL was not distributed with this
+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
+
+#ifndef mozilla_RelativeTo_h
+#define mozilla_RelativeTo_h
+
+#include <ostream>
+
+class nsIFrame;
+
+namespace mozilla {
+
+// A flag that can be used to annotate a frame to distinguish coordinates
+// relative to the viewport frame as being in layout or visual coordinates.
+enum class ViewportType { Layout, Visual };
+
+// A struct that combines a frame with a ViewportType annotation. The
+// combination completely describes what a set of coordinates is "relative to".
+// Notes on expected usage:
+//  - The boundary between visual and layout coordinates is approximately
+//    at the root content document (RCD)'s ViewportFrame, which we'll
+//    call "RCD-VF".
+//  - Coordinates relative to the RCD-VF's descendants (other than the
+//    RCD's viewport scrollbar frames) should be in layout coordinates.
+//  - Coordinates relative to the RCD-VF's ancestors should be in visual
+//    coordinates (note that in an e10s setup, the RCD-VF doesn't
+//    typically have in-process ancestors).
+//  - Coordinates relative to the RCD-VF itself can be in either layout
+//    or visual coordinates.
+struct RelativeTo {
+  const nsIFrame* mFrame = nullptr;
+  // Choose ViewportType::Layout as the default as this is what the vast
+  // majority of layout code deals with.
+  ViewportType mViewportType = ViewportType::Layout;
+  bool operator==(const RelativeTo& aOther) const {
+    return mFrame == aOther.mFrame && mViewportType == aOther.mViewportType;
+  }
+  friend std::ostream& operator<<(std::ostream& aOs, const RelativeTo& aR) {
+    return aOs << "{" << aR.mFrame << ", "
+               << (aR.mViewportType == ViewportType::Visual ? "visual"
+                                                            : "layout")
+               << "}";
+  }
+};
+
+}  // namespace mozilla
+
+#endif  // mozilla_RelativeTo_h

layout/base/moz.build

@@ -82,6 +82,7 @@ EXPORTS.mozilla += [
     'PresShell.h',
     'PresShellForwards.h',
     'PresShellInlines.h',
+    'RelativeTo.h',
     'RestyleManager.h',
     'ScrollStyles.h',
     'ScrollTypes.h',

layout/base/nsLayoutUtils.h

@@ -12,6 +12,7 @@
 #include "mozilla/ArrayUtils.h"
 #include "mozilla/LookAndFeel.h"
 #include "mozilla/Maybe.h"
+#include "mozilla/RelativeTo.h"
 #include "mozilla/StaticPrefs_nglayout.h"
 #include "mozilla/TypedEnumBits.h"
 #include "mozilla/UniquePtr.h"
@@ -132,39 +133,6 @@ enum class DrawStringFlags {
 };
 MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS(DrawStringFlags)
 
-// A flag that can be used to annotate a frame to distinguish coordinates
-// relative to the viewport frame as being in layout or visual coordinates.
-enum class ViewportType { Layout, Visual };
-
-// A struct that combines a frame with a ViewportType annotation. The
-// combination completely describes what a set of coordinates is "relative to".
-// Notes on expected usage:
-//  - The boundary between visual and layout coordinates is approximately
-//    at the root content document (RCD)'s ViewportFrame, which we'll
-//    call "RCD-VF".
-//  - Coordinates relative to the RCD-VF's descendants (other than the
-//    RCD's viewport scrollbar frames) should be in layout coordinates.
-//  - Coordinates relative to the RCD-VF's ancestors should be in visual
-//    coordinates (note that in an e10s setup, the RCD-VF doesn't
-//    typically have in-process ancestors).
-//  - Coordinates relative to the RCD-VF itself can be in either layout
-//    or visual coordinates.
-struct RelativeTo {
-  const nsIFrame* mFrame = nullptr;
-  // Choose ViewportType::Layout as the default as this is what the vast
-  // majority of layout code deals with.
-  ViewportType mViewportType = ViewportType::Layout;
-  bool operator==(const RelativeTo& aOther) const {
-    return mFrame == aOther.mFrame && mViewportType == aOther.mViewportType;
-  }
-  friend std::ostream& operator<<(std::ostream& aOs, const RelativeTo& aR) {
-    return aOs << "{" << aR.mFrame << ", "
-               << (aR.mViewportType == ViewportType::Visual ? "visual"
-                                                            : "layout")
-               << "}";
-  }
-};
-
 /**
  * nsLayoutUtils is a namespace class used for various helper
  * functions that are useful in multiple places in layout.  The goal
@@ -180,6 +148,8 @@ class nsLayoutUtils {
   typedef mozilla::layers::StackingContextHelper StackingContextHelper;
   typedef mozilla::ContainerLayerParameters ContainerLayerParameters;
   typedef mozilla::IntrinsicSize IntrinsicSize;
+  typedef mozilla::RelativeTo RelativeTo;
+  typedef mozilla::ViewportType ViewportType;
   typedef mozilla::gfx::SourceSurface SourceSurface;
   typedef mozilla::gfx::sRGBColor sRGBColor;
   typedef mozilla::gfx::DrawTarget DrawTarget;

layout/generic/nsIFrame.h

@@ -2954,8 +2954,8 @@ class nsIFrame : public nsQueryFrame {
     IN_CSS_UNITS = 1 << 0,
     STOP_AT_STACKING_CONTEXT_AND_DISPLAY_PORT = 1 << 1
   };
-  Matrix4x4Flagged GetTransformMatrix(ViewportType aViewportType,
-                                      RelativeTo aStopAtAncestor,
+  Matrix4x4Flagged GetTransformMatrix(mozilla::ViewportType aViewportType,
+                                      mozilla::RelativeTo aStopAtAncestor,
                                       nsIFrame** aOutAncestor,
                                       uint32_t aFlags = 0) const;