Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electron 10.1.1 app crashes when saving a pdf from the print dialog #25397

Closed
dgmid opened this issue Sep 9, 2020 · 13 comments
Closed

Electron 10.1.1 app crashes when saving a pdf from the print dialog #25397

dgmid opened this issue Sep 9, 2020 · 13 comments

Comments

@dgmid
Copy link

dgmid commented Sep 9, 2020

Preflight Checklist

  • [ x ] I have read the Contributing Guidelines for this project.
  • [ x ] I agree to follow the Code of Conduct that this project adheres to.
  • [ x ] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

  • Electron Version:
    • 10.1.1
  • Operating System:
    • macOS 10.15.6
  • Last Known Working Electron version:
    • unknown

Expected Behavior

I should be able to save a pdf file from the pdf menu without the app crashing

Actual Behavior

the pdf saves, but the app crashes

To Reproduce

Electron fiddle:
https://gist.github.com/c5de74c2973633e178803eef65b827df

Screenshots

pdf-menu

Additional Information

It seems to be any of the options in this menu that crashes the app.
Removing the callback and running it like this:

mainWindow.webContents.print(printOptions)

seems to resolve it -- but I need the callback

@dgmid
Copy link
Author

dgmid commented Sep 11, 2020

Just tried electron 11.0.0-beta.6 and this issue is fixed in that version

@hmt
Copy link

hmt commented Sep 12, 2020

Seems to be a duplicate of #25327 At least I came to the same conclusion in my fiddle :)

@dgmid
Copy link
Author

dgmid commented Sep 13, 2020

@hmt I'm having no problems actually printing from my app -- for me it's the PDF menu in the print dialog that crashes the app.

Looking at it again, the gist I posted is a bit simpler than the actual setup in my app. In my app, on printing I create a new hidden browserWindow with the contents to print in it and then close the hidden browserWindow after printing.

For me, printing works every time using this method. What doesn't work is the PDF menu.
I don't doub't that it is the same bug though!

@hmt
Copy link

hmt commented Sep 14, 2020

I mean, blaming the callback seems to fit both categories. Probably the underlying problem is the same in both instances. PDF printing and printing in general.

@codebytere
Copy link
Member

Yep, this is known - it's not the callback per se as this is specific to the dialog presented by the pdf viewer. The wiring is not the same.

@dgmid
Copy link
Author

dgmid commented Sep 15, 2020

@codebytere thanks for the explanation.
Hopefully this gets fixed soon in 10-x otherwise I'll wait for 11-x as that seems to work perfectly.

@pushkin-
Copy link

I can repro this in 10.1.2 on Windows 10. not mac specific

@pushkin-
Copy link

Is this the same as this issue?

@codebytere
Copy link
Member

codebytere commented Sep 24, 2020

They look different - just tested the other one. I'll try to look today. The other one is reproable in master.

Edit: PR for the other one is now up.

@codebytere codebytere self-assigned this Sep 24, 2020
@alex-drocks
Copy link

alex-drocks commented Sep 28, 2020

Electron v10.1.2
I am getting the crash on Windows 10 with both window.print() and BrowserWindow.getFocusedWindow.webContents.print().
Does not matter if I print to paper or pdf it crashes when the window is closed.

From a Renderer Window, crash happens when the window itself is closed after this function as been called:

window.print();

main.js that produce the crash all the time when invoked:

//todo fix crashing of print
function printNormal() {
    return new Promise((resolve) => {
            const window = BrowserWindow.getFocusedWindow();
            window.webContents.print({}, (success, errorType) => {
                if (!success) return console.log(errorType);
                resolve({success, errorType});
        });
    });
}

@codebytere
Copy link
Member

@alex-drocks that is solved with #25622, which i will backport when i have a moment

@codebytere
Copy link
Member

This issue is fixed by #25530, due out in next release

@alex-drocks
Copy link

Thank you that is awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants