Printing from a Custom HTML Prompt — window.print() is a silent no-op. Any workaround?

[Joel]

I have a Custom HTML Prompt that renders a formatted report (a styled HTML table with a print stylesheet). I want the user to be able to print what they're looking at.

window.print() does not work — and it fails silently. I tested it to be sure, and this is what the prompt reports at runtime:

typeof window.print    = function      (the method exists)
KeyboardMaestro bridge = present
ProcessAppleScript     = AVAILABLE
calling window.print() ...
window.print() RETURNED without error

No dialog, no output, no exception. It exists, it's callable, it returns cleanly, and it does nothing.

I assume the cause is that the prompt runs in a WKWebView, which on macOS has no printing implementation — Apple's own developer forums state there is no method of printing a WKWebView on macOS, and that its print: produces blank pages.

My questions:

1. Has anyone actually succeeded in printing the contents of a Custom HTML Prompt?
2. Is there any KM-native route — an action, a token, or a ProcessAppleScript trick — that renders the prompt's HTML to a printer or to a PDF, without activating a GUI browser?
3. The obvious workaround is to write the HTML to a temp file and hand it to Safari. But Safari must be unhidden and brought to the front to receive the print dialog, which hijacks the user's browser session every time. Is there any way to get a print dialog (or a silent print) without activating a GUI app, and without installing a third-party renderer (wkhtmltopdf / WeasyPrint / headless Chrome)?

ProcessAppleScript is confirmed available inside the prompt, so I can reach out to the system — I just can't find a way to render the HTML that doesn't involve fronting an app or adding a dependency.

Keyboard Maestro 11.0.4, macOS 26.5.2.

[kevinb]

@Joel

Is there any way to get a print dialog (or a silent print) without activating a GUI app, and without installing a third-party renderer (wkhtmltopdf / WeasyPrint / headless Chrome)?

Pending a more elegant solution, might this work?

1. Use a Screen capture action on the front window, saving to system clipboard.
2. Use Write to file set to write system clipboard.
3. Run lpr [path_to_file] in an Execute a shell script action.

(I suspect that the explicit temporary file would not be needed if suitable shell scripting were used.)

[griffman]

I'm pretty sure WKWebView includes print support, so maybe it's just not connected (somehow?) in Keyboard Maestro? In any event, I wasn't sure of an alternative beyond opening a browser window, so I did a bit of web searching.

I found wkhtmltopdf, which will render HTML to PDF using the Qt WebKit engine. However, it's an abandoned project, and installable via a package installer, so I don't want to eat it :). I'm not sure it's a good solution for you, but I wanted to at least mention it.

Then I asked Claude if there were a supported alternative to wkhtmltopdf, and it offered up WeasyPrint, which is live and fully supported:

WeasyPrint

It's also installable via Homebrew, so I tested it out using a not-very-printable form from one of my macros—I just saved the HTML to a file before the Custom Prompt command, then ran weasyprint on it. It rendered it well, given that it's not something really printable, so maybe worth a try?

But if you want real full-on print support, I think you're going to have to jump through a browser window.

-rob.

[kevinb]

@griffman

I found wkhtmltopdf, which will render HTML to PDF using the Qt WebKit engine. However, it's an abandoned project, and installable via a package installer, so I don't want to eat it :). I'm not sure it's a good solution for you, but I wanted to at least mention it.

OP had already mentioned it, and does not want to use that sort of software:

@Joel

Is there any way to get a print dialog (or a silent print) without activating a GUI app, and without installing a third-party renderer (wkhtmltopdf / WeasyPrint / headless Chrome)?

[griffman]

Ooops, missed that, sorry. Please ignore my responses. With that restriction, then the only solution is a browser window or your screenshot method.

Seems to me you could use Safari without hijacking their session by first opening a new window in Safari, then opening the HTML there, printing it, and then closing the new window. Still far from ideal, but it wouldn't lose anything the user is doing in their browser.

Maybe @peternlewis knows why print doesn't work in the Custom HTML Prompt window, and can explain? I'm guessing there might be some security implication.

-rob.

[Joel]

@kevinb and @griffman

Appreciate both your responses.

I will continue to dig but have yet to find the ideal solution.

To date the best solution is through a browser but not something I want to do.

Will try to find / think of a another way to get what I need / want.

Thanks for responding.

[Nige_S]

Try making a Shortcut:

...changing the first action's volume and path to suit (but I suggest you use /tmp).

Set your HTML Prompt's "Print" button to submit the HTML you want to be printed, get KM to save that HTML to the /tmp file path then run an "Execute Shortcut" Action that targets the above Shortcut.

Very limited testing, and I'm sure someone who knows anything about Shortcuts could improve on this -- but it seems to work, at least for simple HTML.

[Joel]

@Nige_S as always, your suggestion worked, and it worked beautifully. Greatly appreciated and much thanks. Posting the result in case it helps anyone else.

The problem. window.print() in a Custom HTML Prompt is a silent no-op. Not an error: the method exists, it is callable, it returns cleanly, and nothing whatsoever happens. I tested the prompt to be certain:

typeof window.print    = function
KeyboardMaestro bridge = present
ProcessAppleScript     = AVAILABLE
calling window.print() ...
window.print() RETURNED without error

No dialog, no output, no exception. The prompt's WebView simply has no print engine behind that method. Every route out of it either hijacks Safari (it must be unhidden and frontmost to show a print dialog) or needs a third party renderer installed. Both were unacceptable.

Your solution, as built. A macOS Shortcut, two actions (I added a third as seen below though it is not entirely necessary and /tmp clears automatically):

Get file   →  /tmp/<report>.html
Print      →  File

That is all. The print dialog appears, the page renders properly, and you can either Print or Save as PDF from it. No application opens. No Safari, no Preview, no browser. no Keyboard Maestro macro needed either The prompt window stays on screen throughout. The output is genuinely clean: title, timestamp, right aligned figures with the decimals lined up, footnotes, proper page margins.

The prompt writes its report to a fixed path in /tmp and calls the Shortcut. /tmp matters: it is not a protected folder, so macOS never asks permission, and the system clears it out on its own. The filename is constant, so each run overwrites the last and nothing accumulates.

One gotcha worth recording. If you add a Delete Files action to clean up, it fails with "This action could not be run with the current user interface." The documented workaround is to insert Continue in Shortcuts App plus a Wait, but that brings the Shortcuts app to the front on every print, which defeats the purpose. Use a Run Shell Script action instead:

Shell:  /bin/zsh
Script: rm -f "/tmp/<report>.html"

No UI dependency, no app switch, no error. (The delete is optional given /tmp self clears, but the shell action is the right tool if you want it tidy.)

What this is part of. I am building a family of themed Custom HTML Prompt windows to replace the native ones: Display Text, Prompt With List, a progress window, and a text input prompt to come. Consistent visual identity, three themes (all have day and night, the three themes are Apple, Ledger, Ink), content driven sizing, and much more. Printing was the last real gap. Your suggestion closed it.

Here are some sample screen shots:

I will post the family here shortly for anyone interested (let me know). Thanks again for taking the time.

PS. It is coded so additional themes can easily be added so very flexible. The progress prompt is teh coolest!

[Joel]

And a daytime / light sample for anyone interested is below. The samples use the Ink theme noting I have also built an Apple theme and a Ledger (i.e., Excel) theme which an be changed on a global or per displayed item basis by simply changing a variable.

The above work work will adda print button so the information can be printed or saved as a PDF. Will update image later today.

The Before

The After

[peternlewis]

@griffman

Maybe @peternlewis knows why print doesn't work in the Custom HTML Prompt window, and can explain? I'm guessing there might be some security implication.

No idea, it's not something I've ever looked at, printing from that window. Keyboard Maestro doesn't support printing in general.