Every resize on the schedule print page asked to print

Flow

Three answers to one repeating dialog

1. 1Strict check⌄

   Only a real true value asks to print, so a window event no longer does.

2. 2Shared flags⌄

   Planning-to-print and already-printed flags keep the viewer out of it. Needs both pages on the same site.

3. 3No automatic print⌄

   No print on load, no timer, no closing the window. A line tells you which shortcut to press.

4. 4Layout stays⌄

   The tidy-up step still runs before printing, so the sheet still fits.

The print page on my staff scheduler had a print dialog that kept coming back. It was meant to pop up once after the page loaded. It didn't stop at one.

Two pages, both pressing print

The print view is really two pages. The inner page holds the schedule and a small layout step that tidies the tables so they fit the printed sheet. The outer page is a viewer that shows the inner page in a frame.

Both pages opened the print dialog on their own. The inner page did it after loading. The viewer did it a moment after showing the frame. Both also closed their window after printing. That's two owners for one dialog, but it isn't the part I'd blame for the repeats.

The event that counted as a yes

The layout step took an optional "print when done" flag. The load code passed true. But the same step was also hooked straight up to resize, rotation, page-show and the moment just before printing. When the browser runs a hook, it passes in an event object. Any object counts as true in that check, so every layout pass asked to print.

window.addEventListener("resize", settle); // settle(event): the event counts as true

The hook that runs just before printing worries me most. I haven't traced it in a browser, but I suspect that's how the dialog came back after being closed.

Three ways the agent answered it

The agent made three changes for this, a few minutes apart, and all three were merged:

• A strict check, so only a real true means print.
• A pair of shared flags, "planning to print" and "already printed," so the viewer stays out of it when the inner page has it covered. This only works while both pages come from the same site.
• Deleting automatic printing. The viewer now shows a line that tells you to use the browser's print shortcut.

The page runs the third one now. The tidy-up step still runs before printing, so the paper still fits.

Why I'd delete it again

Each of those flags was a patch over another way the automatic print could go wrong. Closing the window was the worst part. As far as I know, most browsers report "printing finished" even when you cancel, so backing out could close the page you were reading. Printing now takes one keystroke from whoever wants a copy, and that seems like a fair trade.