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

Print in Electron crashes #108

Closed
rexebin opened this issue Jul 14, 2019 · 19 comments
Closed

Print in Electron crashes #108

rexebin opened this issue Jul 14, 2019 · 19 comments
Assignees
Labels
bug Something isn't working caused by a third-party lib This bug only happens when a certain third-party library is present. Or it's even a bug over there.

Comments

@rexebin
Copy link

rexebin commented Jul 14, 2019

Environment:

  1. Windows: 10 64x.
  2. ngx-extended-pdf-viewer: 0.9.54
  3. Angular: 8.1.1
  4. angular-cli: 8.1.1
  5. electron: 5.0.6
  6. pdf.js: 2.2 (2.1 fails to even render the pdf in electron, delete window["process"] in pollyfiller.ts makes it render, but same printing problem as below.)

Print function is not working in Electron:

  1. click print will pop up system print dialog
  2. if cancel the print dialog without printing, the black "Preparing document for printing" shows at 100%, clicking cancel button offer no response, angular app non responsive, had to refresh window to regain control.
  3. if select a printer, it would print as normal, but electron crash and quit without any warning.

Thanks for the great lib.

@stephanrauh
Copy link
Owner

I don't use Electron every day (although I love it!). May I kindly ask you for a reproducer? Otherwise, I have to figure out how to add Electron to Angular. AFAIK, this has become pretty simply, but still, it's an extra hour of investigation.

@stephanrauh
Copy link
Owner

@timvandermeij @Snuffleupagus This might be interesting to you, too. I've seen a surprisingly small number of issues concerning electron in your repository. Do you officially support it?

@stephanrauh stephanrauh self-assigned this Jul 14, 2019
@timvandermeij
Copy link

No, we don't officially support Electron. If I recall correctly there have been one or two patches fixing polyfills for Electron, but other than that there has been no demand/contributions.

@rexebin
Copy link
Author

rexebin commented Jul 15, 2019 via email

@stephanrauh
Copy link
Owner

@timvandermeij OK, maybe that's a gap I can fill. However, I have to admit it's more likely your library plays well with electron, it's just my Angular integration that's causing trouble. I'll keep you tuned!

@stephanrauh
Copy link
Owner

@rexebin Yeah, I'm definitely interested. For some reason, I'm still busy testing #103, which should be simple, but isn't. So I'll take any support I can get. I'm looking forward to your reproducer!

@rexebin
Copy link
Author

rexebin commented Jul 15, 2019

@stephanrauh I forked the report angular-electron, installed ngx-extended-pdf-view and displayed a pdf file downloaded from your demo page, tried printing in electron, shockingly, no crashes, everything works just fine!

What is different in my own project where electron crashes:

  1. instead of give a pdf to the src, I use pdfMake to generate blob/dataUrl and give them straight to [src] input. It may be a pdfMake or blob/dataUrl issue.
  2. package versions are newer than the ones in angular-electron.

I will try to find a reproducer in with angular-electron and report back here later.

PS: @timvandermeij it may be because pdf.js works with electron out of the box so you don't have much demand/contributions. Let's see.

@rexebin
Copy link
Author

rexebin commented Jul 16, 2019

@stephanrauh It is confirmed, it is Electron 5.0.6 and 5.0.5 bug. Electron 5.0.4 and under are fine with printing. Maybe I should raise an issue to Electron instead.

@stephanrauh
Copy link
Owner

Awesome analysis. I assume the Electron team will find it difficult to trace this bug, so I wonder how to help them. Two ideas: can you wrap the pdf.js showcase as an Electron app? Or, maybe even simpler: I assume Electron can display PDF files natively. What happens when you print the PDF file?

@stephanrauh stephanrauh added caused by a third-party lib This bug only happens when a certain third-party library is present. Or it's even a bug over there. bug Something isn't working labels Jul 16, 2019
@rexebin
Copy link
Author

rexebin commented Jul 16, 2019

@stephanrauh I could make a repo and build a app for them, showing the crash with 5.05/5.06.
At the moment, Electron has a bug with rendering pdf with build-in chromium pdf plugin i.e. the plugin cannot be turned on and Electron always open download dialog rather than displaying the pdf and allow printing. Hence I went for ngx-extended-pdf-viewer for the pdf viewing and printing.

@stephanrauh
Copy link
Owner

I see. It was worth a shot. :)

@rexebin
Copy link
Author

rexebin commented Jul 16, 2019

@rexebin Yeah, I'm definitely interested. For some reason, I'm still busy testing #103, which should be simple, but isn't. So I'll take any support I can get. I'm looking forward to your reproducer!

I had this wired behavior when viewing and printing with ngx-extended-pdf-viewer. I have a set of actions that are set to be hidden on mobile view: fxHide.lt-md = "true. it is a flex-layout setup. After viewing or printing pdf, the actions are sometime hidden regardless of window width. If I shrink window to mobile and back to large, they show up again. Does your lib alter media type?

While I am on this, can I ask if it is convinient to give two events: beforePrint and beforeDownload. I wanted to offer my user to upload a copy of the pdf to the server and save it as an attachment to a record before printing/downloading a pdf version of that record.

@stephanrauh
Copy link
Owner

Sort of. At least temporarily.

In reality, "printing" is sort of cheating in a very clever way. The entire page is hidden via a media query (by adding the attribute data-pdfjsprinting to the <body> tag). The PDF pages are drawn on a collection of canvases, and a new overlay div is added to the page containing these canvases. These canvases are the only part of the page remaining visible when printing. Printing itself is simply the standard window.print() call.

After printing the CSS attribute data-pdfjsprinting is removed again from the body, and the print container is removed.

Maybe this approach confuses the FlexLayouer CSS.

@rexebin
Copy link
Author

rexebin commented Jul 16, 2019

Good to know @stephanrauh . As far as I know, flex-layout is all Javascript no css. The problem is it doesn’t react to the finishing off of printing in this case, resulting the actions to be hidden until a new media query change happens. I will try to find another way to hide the action buttons in this case.

@rexebin
Copy link
Author

rexebin commented Jul 16, 2019

electron/electron#19108 The crash is already reported. I guess we can let go here.

@stephanrauh
Copy link
Owner

Whow, that's probably the shortest reproducer I've ever seen:

document.querySelector('iframe').contentWindow.print()

:)

@stephanrauh
Copy link
Owner

As for the flex-layout bit: oops, I didn't expect it to be all-JavaScript. That's interesting.

It's the same approach I'm doing with #103. In my case, the reason is that the PDF viewer is meant to be embedded. That in turn means it has less than 100% window width. That in turn makes the standard media queries useless. I wonder what the rationale of flex-layout is?

@timvandermeij
Copy link

timvandermeij commented Jul 16, 2019

it may be because pdf.js works with electron out of the box so you don't have much demand/contributions

I certainly hope so because we keep environment-specific tweaks to the bare minimum (and we removed most of them since version 2.0) so the library works for any environment that implements the required JavaScript primitives. Thank you for researching this, and if in the future you find something can be improved in PDF.js, you can always open an issue.

@stephanrauh
Copy link
Owner

I've went over the print CSS again. When you update to version 9.0.0, brace yourself for breaking chances. In your case, that's not likely, but you never know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working caused by a third-party lib This bug only happens when a certain third-party library is present. Or it's even a bug over there.
Projects
None yet
Development

No branches or pull requests

3 participants