fix: crash on print cancellation and silent print settings

[codebytere]

Description of Change

Fixes #19122.
Fixes #17077.
Fixes #19108.
Fixes #19474.

In an earlier PR, I introduced the ability to set custom print options in webContents.print().

However, this meant that the base::DictionaryValue passed in with these settings would never be null, because if even one option is set than they all have to be set with a default to prevent a DCHECK that gets hit if this function returns false. As a result, only the PrintHostMsg_UpdatePrintSettings IPC message would be sent, and printing would silently fail as no defaults were properly initialized. More specifically, since no defaults were set, when a new PrinterQuery was created it would have no idea about previously existing or defaulted settings, since settings were reset at the beginning of print updates.

This fixes that by changing codepaths to intentionally only send the IPC message to update print settings (PrintHostMsg_UpdatePrintSettings), and then each time pursuing the following codepath:

1. Reset settings from previous job
2. Call printing_context_->UseDefaultSettings() in order to set the settings_ member with default settings
3. Call printing_context_->UpdatePrintSettings() with our new settings to only change the options that were passed in.

These custom settings should work now for both silent and non-silent printing: this can be seeing by calling:

win.webContents.print({ copies: 3 }, (success, reason) => {
    console.log(`printing ${success ? 'did' : 'did not'} succeed: ${reason}`)
})

to see that '3' is automatically placed in the UI settings of the native print dialog.

Secondary Fix:

Due to changes in the lifetime of PrinterQuery, a crash occurred if we posted a task to notify of print cancellation and did not also call the callback. This removes that gating and now will call the callback regardless of cancellation status.

I chose not to put this secondary fix in a standalone PR because the primary issue above meant that it isn't even being surfaced to users as it causes a silent failure before a UI printing dialog is ever shown.

cc @jkleinsc @deepak1556

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR title follows semantic commit guidelines
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed a crash on manual print cancellation as well as an issue with deviceName not working.

[fleabitten232]

I'm currently using your changes in a small, heavily print dependent project that needs to silently print to both a standard A4 size/laser printer combination and a notoriously temperamental 6x4inch thermal label printer. I'm happy to share my experiences if you would find that helpful -- just let me know where if here isn't appropriate.

I've now mostly finished moving from electron@latest to electron@beta which broke a label design that was previously working. In latest, it would correctly print landscape (albeit not silently).

In the beta (without any code/css changes), the same label was adamant that it wanted to be portrait. It would print massively scaled down so that the landscape design would fit to the width of a portrait page. This happened with 'silent' sent to both true and false.

I couldn't immediately fix the problem through any print dialog settings and unfortunately I ran out of labels before I could explore deeper. The last thing I noticed was that setting the page to 'landscape' would actually rotate it 180 degrees, rather than 90. Although the printer does have a setting to rotate labels 180 degrees, I'm wondering if the page is somehow being 'landscaped' twice.

I'll have some more labels in the next 24 hours so I'll keep you updated. Unfortunately the project has a looming deadline so if I can't get it working soon I'll have to just rotate the label design 90deg using CSS as a hack and call it done.

[jkleinsc]

Overall LGTM, just one question on updating the test.

[deepak1556]

I am -1 on landing this fix for two reasons,

I introduced the ability to set custom print options in webContents.print(), with the intent that they only be used in silent printing mode.

#18984 that implemented this feature never stated about specifics to silent mode.

• If the settings were not optional at the Printing layer but the implementation is making it optional for users then we should provide the defaults. Which we already seem to do except for some options, we can fix this and make it explicit in the documentation.

• These options are provided to emulate the printing UI provided by chrome, so I don't think it has to be specific to silent printing.

With that said I would propose refactoring the PR which preferred defaults that avoids the crash.

[codebytere]

@deepak1556 i've managed to fix the root issue, and have updated the PR body accordingly :)

[deepak1556]

LGTM, with some clarifications.

[codebytere]

CI failures are unrelated and will be fixed by: #19652

[brenca]

lgtm!

[deepak1556]

👍

[release-clerk]

Release Notes Persisted

Fixed a crash on manual print cancellation as well as an issue with deviceName not working.

[trop]

I have automatically backported this PR to "7-0-x", please check out #19668