Bug 1980356: Don't block in window.print() if there's a registered mozPrintCallback (e.g. for PDF.js) and if any sort of print dialog might be up. a=RyanVM DONTBUILD

dholbert · rvandermeulen · commit a19ee721bd9f · 2025-08-27T01:44:33.000Z
Before this patch, we would unconditionally block in window.print() if the user had the system print dialog enabled. That was problematic because it prevents mozPrintCallback from doing asynchronous work, as described in the nearby code-comment, and this resulted in PDFs printing blank for such users if they used the "print" button (which triggered window.print()). This patch makes the print.prefer_system_dialog codepath share the same logic flow as the regular-print-preview codepath -- now we will *not* block if there's a registered print callback (which allows the callback's microtasks to proceed while the print dialog is still up). Original Revision: https://phabricator.services.mozilla.com/D261296 Differential Revision: https://phabricator.services.mozilla.com/D262701
diff --git a/dom/base/nsGlobalWindowOuter.cpp b/dom/base/nsGlobalWindowOuter.cpp
@@ -5158,23 +5158,29 @@ Nullable<WindowProxyHolder> nsGlobalWindowOuter::Print(
     }
   }
 
-  // When using window.print() with the new UI, we usually want to block until
-  // the print dialog is hidden. But we can't really do that if we have print
-  // callbacks, because we are inside a sync operation, and we want to run
-  // microtasks / etc that the print callbacks may create. It is really awkward
-  // to have this subtle behavior difference...
-  //
-  // We also want to do this for fuzzing, so that they can test window.print().
+  // Check whether we're in a case where we need to block in order for
+  // window.print() to function properly:
   const bool shouldBlock = [&] {
     if (aForWindowDotPrint == IsForWindowDotPrint::No) {
+      // We're not doing window.print; no need to block.
       return false;
     }
-    if (aIsPreview == IsPreview::Yes) {
+
+    // When window.print() spawns a print dialog (either our own tab-modal
+    // dialog or the system-print dialog), we usually want window.print() to
+    // block until the print dialog is hidden. But we can't really do that if
+    // we have print callbacks (mozPrintCallback), because we are inside a sync
+    // operation, and we want to run microtasks / etc that the print callbacks
+    // may create. It is really awkward to have this subtle behavior
+    // difference...
+    if (aIsPreview == IsPreview::Yes ||
+        StaticPrefs::print_prefer_system_dialog()) {
       return !hasPrintCallbacks;
     }
-    if (StaticPrefs::print_prefer_system_dialog()) {
-      return true;
-    }
+
+    // We also want to allow window.print() to block for fuzzing, so that
+    // fuzzers can test either behavior without needing to interact with a
+    // dialog.
     return StaticPrefs::dom_window_print_fuzzing_block_while_printing();
   }();
 
diff --git a/testing/web-platform/mozilla/meta/dom/window-print-mozPrintCallback-async-001.html.ini b/testing/web-platform/mozilla/meta/dom/window-print-mozPrintCallback-async-001.html.ini
@@ -0,0 +1,2 @@
+[window-print-mozPrintCallback-async-001.html]
+  prefs: [print.always_print_silent:true, "print_printer:Mozilla Save to PDF", print.prefer_system_dialog:true]
diff --git a/testing/web-platform/mozilla/tests/dom/window-print-mozPrintCallback-async-001.html b/testing/web-platform/mozilla/tests/dom/window-print-mozPrintCallback-async-001.html
@@ -0,0 +1,54 @@
+<!doctype html>
+<meta charset="utf-8">
+<title>
+  Test for window.print(), with mozPrintCallback making async call to obj.done
+</title>
+<script src="/resources/testharness.js"></script>
+<script src="/resources/testharnessreport.js"></script>
+<canvas id="myCanvas" width="80" height="80"></canvas>
+<script>
+  let t = async_test(
+    "window.print(), with mozPrintCallback making async call to obj.done"
+  );
+
+  // mozPrintCallback needs to ensure that obj.done() will be called, as a signal
+  // that it's done with its rendering work. Here, we make that call via an async
+  // task, scheduled via setTimeout, to mimic the asynchronous work that's
+  // involved in real-life mozPrintCallback scenarios (e.g. PDF.js waiting for
+  // assets like fonts to be ready before it can render the content).
+  myCanvas.mozPrintCallback = function (obj) {
+    setTimeout(() => {
+      obj.done();
+    }, 0);
+  };
+
+  // window.print shouldn't block the main thread for any substantial time here.
+  //
+  // To validate this expectation, we see how soon after calling window.print()
+  // we're able to execute another task on the main thread (scheduled via
+  // requestAnimationFrame), and we expect the delay to be (substantially) less
+  // than this TOO_LONG_WINDOW_PRINT_DUR threshold. (In bug 1980356, we were
+  // consistently overshooting this, because window.print would spawn a task that
+  // would block the main thread until the page print timer "watchdog" kicked in
+  // after ~10 seconds.)
+  const TOO_LONG_WINDOW_PRINT_DUR = 5000; // 5 seconds
+
+  window.addEventListener("load", () => {
+    let timestampBeforePrint = performance.now();
+    window.print();
+
+    // See how soon we're able to execute another task, scheduled via rAF:
+    requestAnimationFrame(
+      t.step_func(function () {
+        let timestampAfterPrint = performance.now();
+        let printDur = timestampAfterPrint - timestampBeforePrint;
+        assert_less_than(
+          printDur,
+          TOO_LONG_WINDOW_PRINT_DUR,
+          "window.print shouldn't block main thread for too long."
+        );
+        t.done();
+      })
+    );
+  });
+</script>

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+[window-print-mozPrintCallback-async-001.html]`
	`2`	`+ prefs: [print.always_print_silent:true, "print_printer:Mozilla Save to PDF", print.prefer_system_dialog:true]`