Share via

ActiveX to AJAX migration: PDF printing no longer automatic in Chrome

T Ken 40 Reputation points
2026-03-18T08:08:38.17+00:00

Hi guys, quick issue I’m stuck on. We have an old VB.NET application that creates PDF files on a network shared folder and used to print them automatically to the default printer using ActiveX. Since Chrome dropped ActiveX support, we replaced that part with AJAX. Now the PDFs are still generated correctly, but they no longer get sent to the default printer automatically from the browser. Any idea how to make Chrome trigger printing to the default printer again?

Windows for business | Windows Client for IT Pros | User experience | Print, fax, and scan
0 comments

Answer accepted by question author

  1. Tracy Le 8,150 Reputation points Independent Advisor
    2026-03-19T10:38:03.96+00:00

    Hi T Ken

    I'll shoot straight with you: if you have absolutely zero control over the client PCs (meaning you can't install local services or modify browser shortcuts), 100% silent, automatic printing from a web page is functionally impossible today.

    Modern browsers like Chrome strictly sandbox the print spooler. They view silent printing as a massive security vulnerability (to prevent malicious websites from instantly draining your ink and paper). ActiveX was basically a sanctioned backdoor that bypassed this security, which is exactly why it was killed off.

    Since we cannot force Chrome to bypass its own security protocols without touching the client machine, here are your only two realistic paths forward:

    1. The "One-Click" Compromise (Hidden iFrame)

    Instead of full automation, you streamline the process as much as browser security allows. You use JavaScript to load the generated PDF into a hidden <iframe> and automatically trigger iframe.contentWindow.print().

    The reality: The Chrome print preview dialog will pop up on the screen. The user simply has to press "Enter" or click "Print" to confirm. It adds one manual keystroke to their workflow, but it requires zero client-side configuration.

    2. Server-to-Printer Direct Routing

    You mentioned the VB.NET app generates the PDF on a network share. Are the physical printers on the same corporate network/VPN as that server? If so, you take the client PC completely out of the printing equation. The browser makes the AJAX call, the server generates the PDF, and then the server immediately sends the print job directly to the target printer's IP address or network queue. The browser never touches the print job.

    Would your users accept having to press "Enter" on a print dialog to use the first option, or are the printers accessible enough by the server to make the second option work? Let me know which direction sounds more viable for your environment!

    Tracy.

    Was this answer helpful?

Answer accepted by question author

  1. Q&A Assist
    2026-03-18T08:08:47.74+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Chrome and other modern browsers cannot access local printers the way Internet Explorer and ActiveX controls did. After removing ActiveX, there is no supported way for Chrome running standard web code (AJAX/JavaScript) to silently and automatically print a PDF to the client’s default printer without user interaction.

    To restore automatic printing, the printing logic must be moved out of the browser sandbox. Typical approaches (not detailed in the provided context) include:

    1. Printing on the server side (have the VB.NET app or a service print directly to a network printer once the PDF is generated).
    2. Using a dedicated desktop component or service on the client that monitors a folder or receives a command from the web app and then prints, instead of relying on browser-based ActiveX.

    There is no configuration change in Chrome or simple AJAX replacement that will re‑enable the old ActiveX-style automatic printing from the browser.

    References:

    Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tracy Le 8,150 Reputation points Independent Advisor
    2026-03-18T08:54:47.57+00:00

    Hi T Ken,

    You cannot replicate silent, automatic printing using pure AJAX in Chrome. ActiveX could do this because it had deep system access. Modern browsers like Chrome intentionally block web code from bypassing the print dialog for security reasons. There is no simple AJAX code that will fix this.

    To get your automatic printing working again, you need to step outside the browser sandbox. Here are the 3 most effective workarounds:

    1. The Quick Fix (Chrome Kiosk Mode)

    If you control the client PCs, right-click their Chrome shortcut > Properties, and add --kiosk-printing to the very end of the Target path. When your AJAX calls window.print(), Chrome will instantly send it to the default printer without showing the preview dialog.

    1. The Best Practice (Server-Side Printing)

    Since your VB.NET app already creates the PDF on a network share, just take the browser out of the equation. Have your VB.NET backend send the PDF directly to the network printer queue as soon as it's generated.

    1. The Modern "ActiveX" (Local Background Service)

    Install a tiny background service (like PrintNode or a custom C# script) on the client machines. Your web app uses AJAX to send a request to localhost, and that local service handles the silent printing to the local printer.

    If this helps clarify your options and saves you from trying to force AJAX to do the impossible, I'd really appreciate it if you could click "Accept Answer" below. It helps others in the community find this solution easily!

    Tracy.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.