Bug 1865172 Part 1 - Always store a page name value when a breakpoint is first found during block reflow. r=dholbert

This happens in a similar location to where we find a breakpoint caused by a
change in page name. However, if the breakpoint was caused by something else,
we still need to compute this value so that the next page being constructed
will have the correct page name.

This also "fixes" the WPT /css/printing/page-name-007-print.html, which passed
before this patch just because our previous logic would continue using the last
page value in those cases, which coincidentally matched what was expected.

Part 2 will include a test that specifically detects this discrepency.

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

layout/generic/nsBlockFrame.h

@@ -848,13 +848,24 @@ class nsBlockFrame : public nsContainerFrame {
                                       LineIterator aLine,
                                       bool* aKeepReflowGoing);
 
+  /**
+   * Indicates if we need to compute a page name for the next page when pushing
+   * a truncated line.
+   *
+   * Using a value of No saves work when a new page name has already been set
+   * with nsCSSFrameConstructor::SetNextPageContentFramePageName.
+   */
+  enum class ComputeNewPageNameIfNeeded : uint8_t { Yes, No };
+
   /**
    * Push aLine (and any after it), since it cannot be placed on this
    * page/column.  Set aKeepReflowGoing to false and set
    * flag aState.mReflowStatus as incomplete.
    */
   void PushTruncatedLine(BlockReflowState& aState, LineIterator aLine,
-                         bool* aKeepReflowGoing);
+                         bool* aKeepReflowGoing,
+                         ComputeNewPageNameIfNeeded aComputeNewPageName =
+                             ComputeNewPageNameIfNeeded::Yes);
 
   void SplitLine(BlockReflowState& aState, nsLineLayout& aLineLayout,
                  LineIterator aLine, nsIFrame* aFrame,