Ngx-extended-pdf-viewer: Print in Electron crashes

[rexebin]

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]

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]

@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?

[timvandermeij]

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]

If still interested, I will have a reproducer repo ready this week.

On Sun, 14 Jul 2019 at 22:00, Stephan Rauh [e-mail] wrote:

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stephanrauh/ngx-extended-pdf-viewer/issues/108?email_source=notifications&email_token=ACTDVBZVUMNOBV47DON2NWLP7OHXXA5CNFSM4IDR6PC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4NHSI#issuecomment-511235017,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTDVBZKJBMEKCPPWLPYL5DP7OHXXANCNFSM4IDR6PCQ
.

[stephanrauh]

@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]

@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]

@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]

@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]

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?

[rexebin]

@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]

I see. It was worth a shot. :)

[rexebin]

@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]

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]

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]

https://github.com/electron/electron/issues/19108 The crash is already reported. I guess we can let go here.

[stephanrauh]

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

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

:)

[stephanrauh]

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]

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.