Arch: x64, though this should also affect x86 builds
OS: Confirmed on Linux and Windows 10
Brief
When a new window is spawned via new_instance:true, only one unattended (i.e., no user interaction) PDF print job can take place at a time.
If more than one "print-to-pdf" job is running concurrently (in separate renderers), the pdf_path option passed to nw.Window.print is seemingly ignored and a "Save As" dialog is spawned by Chromium's printing plugin.
Use case
The use case here is silently generating large batches of PDFs in parallel.
Demo
Steps to Reproduce
package.json
{
"name": "nwjs-issue-5968",
"main": "index.js"
}
index.js
'use strict';
/*
Bug: Any (i > 1) will cause subsequent instances to prompt the user for a
file name, even though one is specified and passed to `nw.Window.print`
in the newly spawned instance. Setting `new_instance:false` "solves" the
problem, but the jobs are now processed serially.
*/
for(let i = 0; i < 3; ++i) {
nw.Window.open('print.html', {
show: true,
new_instance: true
});
}
print.html
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>Test Page</title>
<script>
document.addEventListener('DOMContentLoaded', () => {
// Random ID for PDF file name and payload.
const docId = Math.random().toString(36).slice(2);
document.body.innerText = docId;
const win = nw.Window.get();
// Print to PDF. Should be able to complete without user interaction.
win.print({
pdf_path: `./${docId}.pdf`
});
setTimeout(() => win.close(), 1000);
});
</script>
</head>
<body>
</body>
</html>
Environment
Brief
When a new window is spawned via
new_instance:true
, only one unattended (i.e., no user interaction) PDF print job can take place at a time.If more than one "print-to-pdf" job is running concurrently (in separate renderers), the
pdf_path
option passed tonw.Window.print
is seemingly ignored and a "Save As" dialog is spawned by Chromium's printing plugin.Use case
The use case here is silently generating large batches of PDFs in parallel.
Demo
Steps to Reproduce
package.json
index.js
print.html