Windows printing fails with "Invalid printer settings" in v30.0.4; v29.7.9 works

[dean1012]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug

Printing fails on Windows with the error:

There was an error printing. Invalid printer settings

The problem occurs with both a network printer and Microsoft Print to PDF. Printing from Notepad works successfully.

The issue is not specific to a template or diagram. It also occurs with a completely new blank diagram.

To Reproduce

Steps to reproduce the behavior:

1. Open draw.io Desktop v30.0.4 on Windows 11.
2. Create a new blank diagram.
3. Select File → Print.
4. Select a configured Windows printer.
5. Click Print.
6. See the error: “There was an error printing. Invalid printer settings.”

The same error occurs when Microsoft Print to PDF is selected as the default printer.

Expected behavior

The native Windows print dialog should accept the selected printer and send the diagram to the printer or create a PDF.

Screenshots

Not applicable. The error is reproducible without a diagram-specific visual issue.

draw.io version (In the Help->About menu of the draw.io editor):

• draw.io version 30.0.4
• Electron version 42.3.0

Desktop (please complete the following information):

• OS: Windows 11
• Architecture: x64
• Printer: Windows network printer
• Additional printer tested: Microsoft Print to PDF

Additional context

The following troubleshooting steps were performed:

• Tested with a completely new blank diagram.
• Tested with a custom template and without the template.
• Changed the document from A4 to US Letter landscape.
• Set Microsoft Print to PDF as the default printer.
• Reinstalled the official desktop release.
• Confirmed that the printer works from Notepad and other Windows applications.
• Confirmed that the problem occurs with both the network printer and Microsoft Print to PDF.

As a version comparison, draw.io Desktop v29.7.9 successfully prints on the same Windows installation, using the same printers and documents. This suggests a regression in v30.0.4 or its Electron runtime.

[draw-io-triage-bot]

👋 Thank you for opening this issue!

---

Summary: The user reports a printing regression in draw.io Desktop v30.0.4 on Windows 11 where all print attempts (network printer and Microsoft Print to PDF) fail with "Invalid printer settings," while v29.7.9 works correctly on the same system. This is likely related to the Electron upgrade from v42.x bundled with v30.0.4.

---

📝 Additional Information Needed

To help us investigate this more effectively, could you please provide:

• Have you tried running draw.io Desktop v30.0.4 with the --disable-gpu flag or any other Electron command-line flags to see if it changes the printing behavior?
• Does exporting to PDF (File → Export as → PDF) work as an alternative workaround, even though native printing fails?
• Is this occurring on a fresh Windows user profile, or could any group policies or enterprise printing configurations be involved?
• Can you check if there are any relevant error messages in the developer console (Help → Toggle Developer Tools → Console tab) when the print error occurs?

📋 Bug Report Template

**Environment:**
- draw.io version: [e.g., web app / desktop 24.x.x / Confluence plugin]
- Browser (if web): [e.g., Chrome 120, Firefox 121]
- OS: [e.g., Windows 11, macOS 14, Ubuntu 22.04]

**Steps to Reproduce:**
1. Go to ...
2. Click on ...
3. See error

**Expected Behavior:**
What you expected to happen.

**Actual Behavior:**
What actually happened.

**Screenshots/Files:**
If applicable, add screenshots or attach the .drawio file.

---

---

_{🤖 This is an automated response to help with initial triage. A human maintainer will review this issue. If you've provided all the requested information, no further action is needed - we'll get back to you soon!}

[dean1012]

Have you tried running draw.io Desktop v30.0.4 with the --disable-gpu flag or any other Electron command-line flags to see if it changes the printing behavior?

I hadn't before but I tried now. Printing still fails with "There was an error printing. Invalid printer settings."

Does exporting to PDF (File → Export as → PDF) work as an alternative workaround, even though native printing fails?

File -> Export as -> PDF works fine.

Is this occurring on a fresh Windows user profile, or could any group policies or enterprise printing configurations be involved?

No group policies/AD/enterprise. Just Windows 11 Home Edition. All profiles affected.

Can you check if there are any relevant error messages in the developer console (Help → Toggle Developer Tools → Console tab) when the print error occurs?

Loading draw.io 30.0.4 on a new document without printing contains the following console errors. However, no new console output is generated when attempting to print.

extensions.min.js:2026 failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly module violates the following Content Security policy directive because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".
globalThis.__LIBAVOID_PRINT_ERR @ extensions.min.js:2026

extensions.min.js:2026 warning: Loading from a file URI (file:///C:/path/to/draw.io-30.3.6-windows/resources/app.asar/drawio/src/main/webapp/js/libavoid.wasm) is not supported in most browsers. See https://emscripten.org/docs/getting_started/FAQ.html#how-do-i-run-a-local-webserver-for-testing-why-does-my-program-stall-in-downloading-or-preparing
globalThis.__LIBAVOID_PRINT_ERR @ extensions.min.js:2026

extensions.min.js:2026 Aborted(CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly module violates the following Content Security policy directive because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".)
globalThis.__LIBAVOID_PRINT_ERR @ extensions.min.js:2026

extensions.min.js:2036 [libavoid] wasm load failed; routing disabled: Aborted(CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly module violates the following Content Security policy directive because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".) RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly module violates the following Content Security policy directive because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".)
    at A (extensions.min.js:1918:4420)
    at Kt (extensions.min.js:1918:5996)
    at async extensions.min.js:1921:31865
    at async extensions.min.js:1921:30931
    at async Object.load (extensions.min.js:1918:208)
(anonymous) @ extensions.min.js:2036

extensions.min.js:1918 Uncaught (in promise) RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): Compiling or instantiating WebAssembly module violates the following Content Security policy directive because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".)
    at A (extensions.min.js:1918:4420)
    at Kt (extensions.min.js:1918:5996)
    at async extensions.min.js:1921:31865
    at async extensions.min.js:1921:30931
    at async Object.load (extensions.min.js:1918:208)

[davidjgraph]

Try with latest build

[dean1012]

@davidjgraph I just tried vs 30.3.11 and still same issue. 29.7.9 works as a fallback but the issue is not resolved.

[davidjgraph]

Cause found. Electron 43 rejects print settings, so webContents.print() with any options fails with this error before the dialog opens, on all platforms. Upstream issue: electron/electron#52266, no fix released yet. The next desktop release goes back to Electron 42.7.0 where printing works, plus a fallback that retries without settings if the error ever comes back.

The failure you saw in 30.0.4 was likely a different bug with the same message, the print scale was sent as 1 instead of 100 percent, fixed since 30.2.6.

Please retest when the next release is out.

[davidjgraph]

Fix in 30.3.13