webContents.print() doesn't work under Windows when 'deviceName' is provided

[copystyle]

• Electron Version 6.0.0-beta.12
• Operating System Windows 10 64 bit

Expected Behavior
webContents.print() should send print a job to the specified printer

Actual behavior
Nothing happens. Callback gets called much latter, for example on program exit.

To Reproduce
let print_options = {
silent: true,
printBackground: true,
deviceName: barcode_device_name
}
print_window.webContents.print(print_options, (data) => {
console.log(print result: ${data})
})

Related to #17260

[zlab]

electron 6.0.0, the same problem on win8.1

[jriffel]

I guess I don't understand the release process for Electron. I've been following this bug and its in the "Fixed for Next Release" column on the 6.0.x project. I've been waiting for 6.0.3 to release so I could get this bug fix which we've been desperately waiting on. 6.0.3 just released and this bug is still sitting in the "Fixed for Next Release" column. What is the release process so I can understand when this fix might be released?

[jriffel]

@sofianguy / @jkleinsc can I ask when this bug fix might be released on 6.0.x? I see that 6.0.4 is releasing and it this still did not make it. Is there a release process documented anywhere that would help me understand when this bug fix might move to release? In the 6.0.x project it is sitting in the Fixed for Next Release column but there have been at least 2 releases since it was placed there. Thanks for your contributions!

[jriffel]

6.0.5 and 6.0.6 have now all been released and this bug still remains "Fixed for Next Release":

https://github.com/electron/electron/projects/20

Who can I pay to merge this for the next release :)

[popod]

@jriffel it seems that "project" cannot be trusted to know when an issue will be released..

I've opened this issue to find ways to pay for issues : #18113.

[jkleinsc]

@jriffel @popod Open source is largely volunteer-driven and collaborative. Because of this, time and energy to get things done are often the scarcest resources. We want Electron to be the best that it can be, but we also have to be realistic about what the team maintaining Electron can achieve. This means that:

• We might not have an ETA for when an issue will get investigated or fixed.
• Something you want implemented might not get implemented.
• A change you want merged might not get merged.
• Insisting on or making demands for any of the above is considered against the Electron Code of Conduct

[jkleinsc]

@jriffel maybe a little more context would be helpful here.

What ends up happening is that when issues get fixed, they get fixed in master first and then backported to older versions. Looking at #19598, it appears that it needs a manual backport to 6-0-x (versus an automated backport which usually happens quickly). That manual backport to 6-0-x has not happened yet which is why this issue is still listed on the 6-0-x as fixed in next release versus fixed in 6.0.5/6.0.6

[jriffel]

Thanks so much for the follow up and I very much apologize if I broke the code of conduct. Honestly, I came to this defect with the intent to possibly fix it myself and submit a pull request but it was already fixed. So at this point I'm not sure how I can help but I will if I can. Do you guys accept pull requests from the master back to the 6-0-x branch? Because if so I could probably create that and I'd be happy to contribute. Electron is a great project. I also appreciate some insight on the release process ... we just want to know when we can see it merge down. Thanks again.

[jkleinsc]

@jriffel thanks for your response - it is appreciated! If you'd like to help out the way we do a manual backport is to git cherry-pick the changes to the branch that needs the backport and then fix the merge conflicts and/or compilation errors.

[jriffel]

@jkleinsc - Looking at #19598 this appears to be a fairly substantial change in the API where instead of taking the device name as the 3rd argument an options object is provided which contains device name among many other (likely very welcome) print options. Given this is such a substantial API change would this even be accepted down to the 6-0-x branch if I merge it and submit a pull request? Do you allow API changes like this once a major version (6) is released?

[jkleinsc]

@jriffel we do not allow breaking changes into a major released version, but we do allow the addition of features in point releases (eg 6.1.0). If the change could be backported in a way where the old API still works then a 6.1.0 would work; otherwise the change would have to be completely refactored to work under the 6-0-x APIs.