0f04bc47ad
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/D262703
Common testing tools for mozilla codebase projects, test suite definitions for automated test runs, tests that don't fit anywhere else, and other fun stuff