@sethlu @gnahzak have either of you had time to work on this?

This is still a 3.0.0 blocker

@ckerr We didn't get to make much progress since https://github.com/electron/electron/pull/13760 opened.

How can a "stable" version be released while this is not fixed? I spend hours trying to find out why my application didn't work after the update..

3.0.0 is a new major release, by definition this can contain "changes that break backward compatibility". They might have their reasons why they excluded this for 3.0.0, but yeah, I think removing features like this is no that cool as well...

How can a "stable" version be released while this is not fixed? I spend hours trying to find out why my application didn't work after the update..

It’s horrible! Even until now they have not fixed...

We chose to drop native PDF rendering support from the 3.0.0 release because we don't have enough people to continue maintaining it, and it is not a widely used feature. This was noted in the release notes. We're still interested in bringing it back, but nobody on the core team has the available time to work on it currently, so it's stalled for the foreseeable future. If you want to see it make a comeback, please have a go at making a PR!

I would really appreciate to get this working again. How can I help?

Is there any way I can make it work in my app without having to use an outdated version?
Should I use https://github.com/electron/electron/tree/enable-pdf-plugin? If yes, how?

Best way to start would be by getting a local build of electron running, and specifying the enable_pdf_viewer = true build option in the gn gen step, e.g.

$ gn gen out/Debug --args='import("//electron/build/args/debug.gn") enable_pdf_viewer=true'

(or equivalently, edit out/Debug/args.gn after running the regular gn gen step and add the enable_pdf_viewer = true argument.)

Best way to start would be by getting a local build of electron running, and specifying the enable_pdf_viewer = true build option in the gn gen step, e.g.

$ gn gen out/Debug --args='import("//electron/build/args/debug.gn") enable_pdf_viewer=true'

(or equivalently, edit out/Debug/args.gn after running the regular gn gen step and add the enable_pdf_viewer = true argument.)

How can I do that with electron-builder?

electron-builder, despite the name, is not a tool for building electron itself. You'll need to follow the instructions for building electron itself.

(the above reference was in error; I was cleaning my clipboard and it went off.)

electron-builder, despite the name, is not a tool for building electron itself. You'll need to follow the instructions for building electron itself.

If it's just a flag why isn't it enabled in the official build?

If it's just a flag why isn't it enabled in the official build?

Enabling the flag doesn't actually make it work, in it's current state it simply adds the required deps and files to the Electron build process. These files have compile errors and cause crashes when running, these compilation issues and crashes need to be fixed before it can be enabled in the official build.

FYI... if you need PDF viewer support in 3-0-x now, you can use https://github.com/gerhardberger/electron-pdf-window. I just tested it on Electron 3.0.8 and it works perfectly.

Thanks @jkleinsc unfortunately your solution won't work with an iframe.
In my fork of 3-0-x i tried to fix the PDF viewer with this commit.

This compiles and links, unfortunately PDF still doesn't work, i debugged and found that:
In AtomResourceDispatcherHostDelegate::ShouldInterceptResourceAsStream()
GetAssociatedRenderFrame returns -1 and -1.

When i debug on 2-0-x branch i don't get -1 values and PDF works.
Can anyone help me? Maybe you @deepak1556 ?

We chose to drop native PDF rendering support from the 3.0.0 release because we don't have enough people to continue maintaining it, and it is not a widely used feature. This was noted in the release notes. We're still interested in bringing it back, but nobody on the core team has the available time to work on it currently, so it's stalled for the foreseeable future. If you want to see it make a comeback, please have a go at making a PR!

Hi @nornagon What I can see in the release notes is that "PDF Viewer is currently not working but is being worked on and will be functional once again soon".
This message was pretty positive, much more than "it is not a widely used feature". By the way, do you have any statistics about this last statement?

I know this is not StackOverflow but for the time being I'm using

shell.openItem(fullPath)

to use the system pdf viewer which is installed on most systems anyway and which also has a print option which seems to be missing even from [email protected]

Is there any work planned for the next major release? We're still on electron v2.0.16 because of the PDF viewer.

v4.0.0 just released and according to Support Doc you only support the latest 3 release branches. It would be nice if we could get the PDF viewer in v5 back to keep getting security patches.

@jkleinsc Is this being actively worked on? Otherwise I'm going to work on a fix.

@chriswald I am working on this but haven't finished it yet, so if you have a fix ready to go let me know; otherwise I'll finish the work I've started.

I've resolved most of the build errors but am hung up this morning on generating the pdf_viewer_resources files. Can we chat in the Slack so we're not spamming everyone in this thread?

@chriswald sure we can chat in Slack.

@jkleinsc Have you made any progress? I haven't been able to connect with you on Slack, but I'm looking to get an understanding of whether I should continue investing time in a fix.

Yes please do @chriswald!

This is a 3.0, 4.0, and a 5.0 beta blocker for us, so we are stuck with 2.0. @walltex for more details.

@chriswald I'm working on addressing the issue for 5-0-x and 4-0-x. At this point I'm not planning on addressing 3-0-x, so if that's something your interested in looking into, go for it.

@jkleinsc Perfect! Do you have an estimated date when the fix will be ready?

@chriswald good question. I should be able to figure out an ETA this week. Due to the shift we made in 4-0-x to use GN for building, the 4-0-x and 5-0-x PDF support is going to be a rewrite as opposed to trying to shim in what we did for earlier versions.

@jkleinsc "going to be a rewrite" > That's what I'd been seeing too, it's good to know I was on the right track. Target completion is the last factor I need to decide whether I need to continue working on this to meet our own timelines. Thank you for your update! Please keep me posted!

@chriswald after digging in a little further and looking at my schedule, I'm conservatively estimating to have a resolution by the end of the month. It may get done sooner, but I need to be realistic as I am traveling 2 out of the 4 weeks in February.

@jkleinsc Thank you for the update! That sounds fine to me, and fits well into our own timelines. I'll keep my development environment set up in case something comes up, so if that estimate gets pushed out please let me know and I may be able to jump back in. Thank you!

Any update on the status of this ?

Draft/WIP PR here: https://github.com/electron/electron/pull/17163

Is there any milestone?
I'll probably move my project to 2.0.x branch because I really need the viewer. But having it fixed in stable 3.x would be far better.

@jkleinsc how much did you progress? Any good results?

@vsvipul it is coming along but unfortunately other responsibilities have slowed my progress. I'm hoping to work on it this week and next

Maybe someone can help me with this workaround here. I'm kinda lost.
I've got an angular-project which uses electron with the electron-packager to get an executable. I had a look for the features.gypi in my electron package and in my local node_modules without success. Could someone tell where to find this?

@Corebee Everything, including all currently possible solutions, is summarized in the accepted answer of this question:

https://stackoverflow.com/q/52844135/7910454

@Corebee Everything, including all currently possible solutions, is summarized in the accepted answer of this question:

https://stackoverflow.com/questions/52844135/view-pdf-in-electron-browserwindow

Ah thanks, haven't seen this. I'll give it a shot, until there is proper solution. Thanks @MiXT4PE

@jkleinsc is there any news regarding the update? Also, if there is any way I can help with it, I'll be happy to.

@DmitryMK it turns out that implementing in 5-0-x and newer is going to require us to have the network service enabled. There is work underway here to enable that: #15791

@jkleinsc thank you for the update. It looks like enabling the network service itself is a big task. Just to clarify, does it mean that PDF viewer will not be in versions 3 and 4?

@DmitryMK The work I am doing is centered on getting it working in master, which will probably at this point be 6-0-x. If we can backport we will, but given the network service requirement I doubt it will make it to 3 and 4.

@jkleinsc - Is there an estimation when there will be an electron version containing the fix?
From your answer to DmitryMK I understand that we shouldn't rely on backporting the fix to Electron 4?
That's a big regression that affects many applications and prevents upgrading from electron 2.0.X until there will be a version that will contain the fix

@jkleinsc how we can help? https://github.com/electron/electron/pull/17163

@arnaudbud thanks for asking. I have been trying to get it working but I think my approach of trying to stick closely to what Chromium is doing isn't going to work until we have more robust support for extensions. There is a PR here #17440 that is attempting to do that. At this point I'm going to punt on this, so if anyone else wants to take a swing at it (perhaps in an approach that doesn't require extension support) feel free to do so.

@jkleinsc so does that mean there is no chance for the native PDF viewer to be implemented in v6.x?

Running Electron 6.0.0-beta.4
Still no pdf support 👎

@mailtokartik1 it is possible it could make its way to 6.x if someone works on it, but that I know of, no one is working on it.

curious, is a c++ required to contribute to Electron?

What does the built in PDF viewer support that can't be achieved using PDF.js?

Nothing as far as I am aware, but would save having to refactor codebase in old applications.

I looks like it would be relatively easy to create a BrowserWindow which loads the required PDF in the PDF.js viewer. Here is an example I found for doing that.

Just make sure you include all the relevant PDF.js files.

We're using PDF.js to load previews into our main UI and have only good things to say about it. It's the viewer used in Firefox so it is well tested.

@beig refs #12337

"It was disabled during the Chromium 63 upgrade in #11459.
Please turn enable_pdf_viewer flag in the features.gypi on, fix compilation and tests."

Could we get this in next beta?

That leaves out embedded pdf's, dont need a whole new window opening --

@Nashorn the example I linked to should work equally well for WebView etc.

Seems that now isn't working too...
I'm trying to use object tag with application/pdf and nope...

@dalexhd If you are okay with it opening in a new window check out this answer: https://stackoverflow.com/q/52844135/7910454

You mean, setting plugins to true? If that is the case, it's still not working....
If not, please go a bit in depper...
¿How can I display pdf like in chrome, in Electron?

Is it possible to achieve exactly the same behavior as the built-in PDF viewer, by using pdf.js ?
Before the built-in viewer was even a thing (I think electron v1 or even early v2), I tried a solution using pdf.js but it felt overly complicated.

Rendering PDF's through pdf.js worked well when I knew ahead of time that the content type was application/pdf, as I could grab the resource URL and pass it via query parameter to a local copy of pdf.js, then display that in it's own window or just inline inside an <iframe>.

But I couldn't find a nice solution to rendering a PDF which is a part of content rendered in an <iframe> (or an <iframe> inside of an <iframe> several layers deep etc.), as I don't believe I could rewrite those iframe's src to point to pdf.js

Is there a way to detect all content of type application/pdf and render it via. pdf.js, even if it is content embedded several layers deep in <iframe> elements?

This is something that just worked with the built-in viewer and is my main objection to PDF.js becoming the permanent "solution" unless anyone can help me with my above struggles :) :) :)

@chris-ls in my case, my pdf are with dynamic inputs, so my company can't fill them with pdf.js.

I also have pages with inline PDF viewing, not able to modify hundreds of pages to do this type of wireup, besides I have no access or allowed to modify the incoming HTML/js

Embedded/inline PDF provides our apps much needed context;
It's valuable to glance at PDF content within a broader view.

Chrome's PDF plugin is superior to all the React pdf.js implementations I have taken for a test drive thus far, both in performance and simplicity/robustness.

Can we please enable embedded/inline PDF support in Electron Chrome in a future release, or have a PATCH configuration to follow for the interim.

thumbs up to that

This is really blocking issue for me, my application is designed for corporate use with pdf certificate generation from database.
This is must needed feature for me..

@jkleinsc, you removed your assignment - is this issue still being worked on?

@MiXT4PE that I know of, no one is currently working on this.

@jkleinsc That's a real bummer. What are the difficulties?

I would really like to know. All the work-arounds given by team and others are far from acceptable. We need a seamless, native way to use object and/or iframe to show PDF's embedded.

@MiXT4PE the main thing I ran into trying to port over Chromium's viewer was its dependency on the chromium extension system. Electron supports only a portion of that system which made it difficult to integrate the viewer.

@jkleinsc Why did it work with Electron 2.x and has stopped working with 3.x and higher? Was the pdf viewer in Chromium 61 (Electron 2.x) not dependent on the Chromium extension system?

When 2.X.X stops receiving security upgrades soon this situation will go from terrible to disastrous...

I quote the 3.0.0 release notes:

PDF Viewer is currently not working but is being worked on and will be functional once again soon

@MiXT4PE 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 I I'm agree with you... But take on mind, that this is a very important feature that stoped working after the 2.0 version relaeded. Can you explain us why this "bug" isn't being investigated?
Thaks for all patience ^^.

@dalexhd unfortunately it isn't a priority for the companies who pay core Electron maintainers and I don't know of any volunteers who are willing to work on it in their free time. The original implementer of this feature moved onto another company who doesn't need that feature.

All: This is the Open Source game.. If you want a feature: do it, pay for it or wait ;)

@jkleinsc What about adding this repo to issueHunt or Github Sponrors like I suggest in this issue #18113 ? This could motivate people to works on features like this one..

@popod yes this issue would be a great fit something like IssueHunt. I'll pass it along to the other maintainers.

wth. ?
You mean, we can get paid to add features/bug-fixes (~~brain bombed)?

I am willing to put up $1000 for this feature. Anyone else?

Ich bin derzeit nicht im Büro. Ich kehre zurück am 05.08.2019.
Ich werde Ihre Nachricht nach meiner Rückkehr beantworten.

Die Rückmeldung bezieht sich auf ein Mail mit folgendem Thema:
Re: [electron/electron] Enable PDF Viewer (#12337)

Gesendet (c) GRZ/RACON Linz 2019 Agent 'Abwesenheit'

Raiffeisen Software GmbH
Firmenbuchnummer: 86804d, Landesgericht Linz
DVR: 0572934, UID: ATU 36961105

Der Austausch von Nachrichten mit dem oben angeführten Absender via E-Mail
dient ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen
dürfen über dieses Medium nicht ausgetauscht werden.
Correspondence with above mentioned sender via e-mail is only for
information purposes. This medium is not to be used for the exchange of

legally-binding communications.

@jkleinsc Now that better extension support is on its way with #17440 - do you think the work on this issue will be picked up again?

@MiXT4PE hopefully. I am going to at least update #17163 to pull in the changes from #17440 and see if the current work there unblocks stuff.

@jkleinsc Thank you!

Thanks 👍

I don't know how much this will help you guys but there can be a temporary workaround for the PDF issue by using Mozilla pdfjs until Electron supports native PDF in the near future. The mimeType of the download item in Electron can be checked and routed to the viewer.html for pdfjs to open and load the pdf in the Mozilla PDF viewer.

A small working snippet can be as follows:

function createWindow () {
  // Create the browser window.
  session.defaultSession.on('will-download', onDownload);
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true,
      webviewTag: true
    }
  })

function onDownload(event, item, webContents) {
  console.log('onDownload');
  // Prevent from downloading pdf file.
  if (item.getMimeType() == 'application/pdf' && item.getURL().indexOf('blob:file:') != 0) {
    event.preventDefault();
    BrowserWindow.getFocusedWindow().loadFile(path.resolve(__dirname, "pdfjs/web/viewer.html"));
    //mainWindow.loadUrl(path.resolve(__dirname, "pdfjs/web/viewer.html"));
  }
}

I have a working demonstration of the same here: https://github.com/mailtokartik1/sampleElectron.
Obviously, you can add the pdfjs as a remote but this is just a working demo. Hope this helps somebody.

@mailtokartik1 Mozilla pdf.js doesn't support field completion. This is the main issue.

@dalexhd yes but I figured there isn't any helper workaround code for the this issue on this thread and maybe, some people are just looking for a workaround.

Hi @mailtokartik1
could you explain how this work-around will work at a high level? Seems like it intercepts the request and redirects to a viewer, but i don't see the var "encodedUrl" being used. ?

Hi @Nashorn
Yeah the encodeUrl isn't used here, I was trying to get the encodedUrl of the webpage and display it to the user but then, it worked fine without it and I didn't feel it was necessary(Edited the comment btw). About the explanation, Electron's default behavior is to download the pdf links, so basically if we listen to the will-download event and check if it's a PDF, then we can route the contents to the pdfjs viewer.

@mailtokartik1 I don't think this works for embedded PDF files.

I want to have PDF files embedded into the HTML via an iframe and it just redirects to a white screen when I implement what you have done.

@teckwrek I am willing to put up $1000 for this feature. Anyone else?

I'll easily add $500 to that pot. @jkleinsc : Did anyone get an Issuehunt set up?

I am willing to add my insane gratitude because I'm poor.

@jkleinsc Did you make any progress? Also: What would be the procedure to pay for this feature?

@MiXT4PE unfortunately no. IssueHunt appears to want more GitHub permissions than we are comfortable with, but anyone is free to open up a bounty on BountySource or a similar platform.

@jkleinsc Are there more important issues right now or is it being blocked by something else?

@DanielJackson-Oslo @teckwrek You can put a bounty on this issue over on https://www.bountysource.com/issues/56240517-enable-pdf-viewer

@teckwrek @MiXT4PE Added my $500

@jkleinsc Any other way we can help get this done?

@DanielJackson-Oslo Easiest way around this by far is to just add the pdf.js viewer code from here [click Stable (v2.1.266)] to some static folder in your electron app and load in an iframe src="statics/pdfjs/web/viewer.html?file=file:///path/to/some.pdf" or even a base64 encoded pdf like src="statics/pdfjs/web/viewer.html?file=data:application/pdf;base64,<data>"

[edit] The latter is probably subject to a 2mb URL limit though, unless that has been lifted in recent chromium or electron.

@mosu-forge Thank you. For now there are issues with pdf.js and Create react app, which I didn't manage to resolve last time around. I'll get to it later, but it still feels like a hack. Fixing this issue and getting it from Chromium would make for a much nicer solution.

See https://github.com/wojtekmaj/react-pdf/issues/413 and https://github.com/wojtekmaj/react-pdf/issues/291 as well as https://github.com/mozilla/pdf.js/issues/10813

I haven't tried adding it myself like you describe there, will put it in the backlog :)

Solutions exist to display PDF documents, however Chrome's implementation is by far superior, hence our weight on this issue; Chrome's PDF plugin is superior to all the React pdf.js implementations I have taken for a test drive thus far, both in performance and simplicity/robustness.

@mosu-forge

Also, including pdf.js seems like an unnecessary "hack" when Chromium has native PDF reading support.

It's a lot easier to just let Chromium deal with it instead of having to scan the whole page for any frame that has a PDF source and replace it with a pdf.js viewer, at least in my opinion. (Example based off of my usage requirement.)

@teckwrek > I am willing to put up $1000 for this feature. Anyone else?

It's available here: https://www.bountysource.com/issues/56240517-enable-pdf-viewer
Just a reminder!

@MiXT4PE @DanielJackson-Oslo Added my $1000

@jkleinsc Please!

I have problems running tests, anybody could assist me? I want to try to solve it

My tests are failing on fresh installation. I assume I must get it to work until I'll start my changes - could you help with running them?

Used node version: v8.16.0
OS: Linux x64 kernel 5.* (KDE neon)
all libraries installed and tools compiled as in documentation

Running: Main process specs
Unhandled exception in main spec runner: electron/spec-main/api-net-spec.ts(1055,29): error TS2345: Argument of type 'ClientRequest' is not assignable to parameter of type 'WritableStream'.
  Property 'writable' is missing in type 'ClientRequest' but required in type 'WritableStream'.

Traceback (most recent call last):
  File "/home/tcd/electron-gn/src/electron/script/dbus_mock.py", line 28, in <module>
    subprocess.check_call(sys.argv[1:])
  File "/usr/lib/python2.7/subprocess.py", line 190, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/home/tcd/electron-gn/src/out/Debug/electron', 'electron/spec-main']' returned non-zero exit status 1
✗ Electron tests failed with code 1.
npm ERR! Test failed.  See above for more details.

Any updates? @jkleinsc

Can anyone provide a reasonable estimate of what it might take $-wise to make this a priority? Is it feasible to have ready by April 2020?

Can anyone provide a reasonable estimate of what it might take $-wise to make this a priority? Is it feasible to have ready by April 2020?

Apparently >$1,600 (https://www.bountysource.com/issues/56240517-enable-pdf-viewer)

I see that’s what’s been committed, I’m asking for someone to write that code what would it take. At $1600 we are still waiting for a solution. Is $4000 a better target? $16,000? I don’t know the level of effort involved in what needs to be done so it’s difficult for me to know what is reasonable.

Sent from my iPhone

On Dec 8, 2019, at 9:31 AM, Leon Heess notifications@github.com wrote:


Can anyone provide a reasonable estimate of what it might take $-wise to make this a priority? Is it feasible to have ready by April 2020?

Apparently >$1,600 (https://www.bountysource.com/issues/56240517-enable-pdf-viewer)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

@namotco You can set a bounty that expires. Just select expiration in 3 months and pledge whatever you are willing to pay for this feature. Either you get the feature until then or you get your money back.

relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=702993

This should be ready to test out in the next 10.x nightly. I'm hoping to backport to 9.x as well, though it may not end up sticking if it causes issues.

OH MY GOD THANK YOU SO MUCH YOU BEAUTIFUL BEAUTIFUL PERSON!!

I can confirm that in latest nightly build (10.0.0-nightly.20200216) PDF viewer works again. Thanks for hard work to everyone involved.

Thank you for this long-awaited feature!
Does this somehow include the ability to print?

Thank you for this long-awaited feature!
Does this somehow include the ability to print?

In my app, PDF print still does not work. I'm getting these errors "ipc_message_attachment_set.cc MessageAttachmentSet destroyed with unconsumed attachments"

Hi @nornagon .... I confirmed that PDF viewer works and my part of the bounty is yours!

Could I request that the download and print functionality be fixed as well?

@godza @teckwrek It's a known issue at the moment. @nornagon wanted to release a working PDF viewer first and tie up the rest afterwards. Thanks again @nornagon !

See follow-up issues:

22179

22178

22180

@nornagon thanks for fixing the PDF. I saw that it's supposed to be in Electron 9.0.0-beta.2 unfortunately i only get a grey background and 3 icons when i try to load a PDF file.

@Order256 Ah, yeah, I'm seeing the same thing. Opened https://github.com/electron/electron/issues/22286 to track the issue.

I'm not sure what to do with the bounty on my end, when i tried it with [email protected] and I assume I hit bug #22286

@pbmzero do you have a link to the pdf you're having trouble with? https://gist.github.com/248085f4c2376e9211479f2d09634050 this works for me in 10.0.0-nightly.20200218.

@nornagon Ok it worked if i loaded the PDF directly like you showed in your code snippet.

I expected that it would work inside iframe per this example: https://www.w3docs.com/tools/code-editor/1087

This example works for me in an iframe: https://gist.github.com/c097b618d2c1cfccf99c6a80fb15c550

@nornagon Indeed it works. I'll go ahead and release bounty. Hoping this sticks!

For me [email protected] is working perfectly for six PDF view cases I've got -- this is excellent work, many thanks! Just hoping to get print feature.

I've tried latest 9.0.0 build (beta 3) and pdf preview is working for me now. Thanks again!

Any idea when version 9.0.0 beta 3 or greater (even version 10) will become an official release?

@waltder Electron 9 stable date has been moved to Chromium's M83 stable date, May 19th. There is a PR in process here https://github.com/electron/electronjs.org/pull/3770 to update the website.

@jkleinsc Thanks for the info.

Will the print and download features be fixed any time soon?

Great news that the pdf viewer is working again. Thank you very much!
There already exist two open tickets for printing #22179 and downloading #22178

@nornagon Are you going to work on these tickets too? Or can you give an estimate of the effort?

Hello! i'm using Electron 9.0.5 stable but when i try opening a pdf it's a grey screen. Am i missing something?

Hi,
On my side this bad behaviour was due to this simple piece of code app.commandLine.appendSwitch('disable-site-isolation-trials');
I don't understand the relationship between the PDF feature and this part of the code but when I remove it, it works as expected.