feat: enable pdf viewer by nornagon · Pull Request #21794 · electron/electron

nornagon · 2020-01-16T00:00:46Z

Description of Change

This builds on top of the native extensions support work that's been ongoing (see #19447) to implement the pdfium-based PDF viewer, the same one that Chrome uses.

Fixes #12337.

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: Restored support for pdfium-based PDF viewer.

…rome-pdf handlers

BUILD.gn

shell/app/atom_content_client.cc

shell/browser/atom_browser_client.cc

shell/browser/extensions/atom_extensions_browser_client.cc

shell/browser/extensions/electron_component_extension_resource_manager.cc

shell/browser/plugins/plugin_response_interceptor_url_loader_throttle.cc

shell/browser/plugins/plugin_utils.cc

trop · 2020-02-11T00:07:03Z

@nornagon has manually backported this PR to "9-x-y", please check out #22131

deepak1556

LGTM

I am good with the merge, can make changes in a follow up PR as the diff is quite big.

BUILD.gn

deepak1556 · 2020-02-09T02:13:37Z

shell/app/electron_content_client.cc

+  // loaded. However, in Electron, we load the PDF extension unconditionally
+  // when it is enabled in the build, so we're OK to load the plugin eagerly
+  // here.
+  content::WebPluginInfo info;


why do we want to load the plugin eagerly ? What happens if we let it to load with the default flow when the pdf type is encountered by the renderer.

Its weird to see the redeclaration of the plugin info just for eager loading.

Yeah, I agree it's a little weird to see. The reason I did it this way was to reduce the amount of machinery we need to pull in. Currently we have nothing that listens for extension loads, and it was easy enough to put it here. If there's a good reason to make it lazy later on, we can do so. I think this is fairly light in terms of the amount of work it does though so I think it's OK for it to be eager.

deepak1556 · 2020-02-11T00:05:39Z

shell/browser/electron_browser_client.cc

+
+  // There is nothing to do if no ElectronExtensionWebContentsObserver is
+  // attached to the |web_contents|.
+  if (!web_observer)


The lifetime of the observer based on WebContentsUserData should be based on the lifetime of the WebContents , so the above check for if (!web_contents) would be good, this is redundant.

I'm not 100% sure that we never create a WebContents without an ElectronExtensionWebContentsObserver, so I think this check should stay...

(fwiw, I'm pretty sure we sometimes create content::WebContents without an electron::api::WebContents wrapper, and in that case we might not have created the observer I think?)

shell/browser/electron_browser_client.cc

deepak1556 · 2020-02-11T00:19:33Z

shell/browser/electron_browser_client.cc

+      extensions::ProcessManager::Get(web_contents->GetBrowserContext())
+          ->GetBackgroundHostForExtension(extension->id());
+  if (host) {
+    factories->emplace(url::kFileScheme, std::make_unique<FileURLLoaderFactory>(


Will this override the file url loader handled by the network service https://source.chromium.org/chromium/chromium/src/+/master:content/browser/frame_host/render_frame_host_impl.cc;l=5594 ?

I'm not sure... I copied this logic from Chrome so maybe? How would we tell?

shell/browser/extensions/api/tabs/tabs_api.cc

shell/browser/plugins/plugin_utils.h

deepak1556 · 2020-02-11T00:38:17Z

shell/renderer/renderer_client_base.cc

+  info.name = base::UTF8ToUTF16("Chromium PDF Viewer");
+  info.path = base::FilePath::FromUTF8Unsafe(extension_misc::kPdfExtensionId);
+  info.background_color = content::WebPluginInfo::kDefaultBackgroundColor;
+  info.mime_types.emplace_back("application/pdf", "pdf",


would be good to keep the same constants between the utility class plugin declaration and here.

agree, I think Chrome does some other stuff to deduplicate this. I'll clean up in a followup.

deepak1556 · 2020-02-11T00:46:19Z

spec-main/chromium-spec.ts

+      w.loadURL(pdfSource)
+      const [, contents] = await emittedOnce(app, 'web-contents-created')
+      expect(contents.getURL()).to.equal('chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html')
+      await emittedOnce(contents, 'did-finish-load')


Is there a better signal or chrome api we can run to see if the pdf is actually loaded , maybe https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/resources/pdf/pdf_viewer.js;bpv=0;bpt=0;l=1521 ? did-finish-load on the webcontents wouldn't exactly denote that the extension rendered the pdf.

i tried a lot of things to try to get a better "loaded" signal but nothing i tried worked. the core issue is that the MimeHandlerGuestView is similar to a <webview>, and it doesn't forward any kind of messages out of the <embed>. the best idea i have is to make preloads work in extension pages and use that to add some hooks, but we don't have that capability yet.

I'm currently having some issue loading larger PDF file. Is this somehow related?

@ericshung no, I don't think that's related, but I'm seeing some other issues with that PDF (including discovering a bug in Chromium itself: https://crbug.com/1051548). Thanks for the report.

shell/browser/extensions/api/resources_private/resources_private_api.cc

nornagon · 2020-02-13T00:39:02Z

There's still some work to do on this, but I think this is a good first pass and is ready to merge. I'll open issues for:

Download functionality. This should work similarly to regular download requests from web pages. PDF download button doesn't do anything #22178
Printing. Print from PDF #22179
Some incrementally-loaded PDFs don't load past the first page (e.g. https://www.hq.nasa.gov/alsj/a17/A17_FlightPlan.pdf) Some incrementally-loaded PDFs only load the first page #22180

release-clerk · 2020-02-13T00:39:16Z

Release Notes Persisted

Restored support for pdfium-based PDF viewer.

tomsontom · 2020-02-19T08:23:41Z

I tried the beta.2 support but my PDFs are NOT rendering in there! If I use the 10.0.0-nightly they do! I don't see any error message, ... so I'm not sure how I could debug why things work in the nightly but fail in 9.0.0

exentrich · 2020-02-24T13:24:43Z

@tomsontom Same issue

nornagon · 2020-02-24T17:02:43Z

See #22286

rgilotra · 2020-03-26T16:36:57Z

Hi I am posting this comment w.r.t. nightly version 10.x. I see PDF viewer working in development mode. but as soon as it is packaged it reflects same issue "Save As dialog" box as with stable version 8.x.
npm i electron-nightly@10.0.0-nightly.20200310
Could anybody suggest something ?

nornagon added 5 commits January 15, 2020 15:56

wip

6a432e0

wip2

39e4fa0

load component extensions from pak files

87acc7e

allow loading from chrome: scheme

ee767a9

resolve collision between application/pdf and application/x-google-ch…

79e5fc4

…rome-pdf handlers

nornagon added the wip ⚒ label Jan 16, 2020

electron-cation bot added the new-pr 🌱 PR opened recently label Jan 16, 2020

refactor blink_initialization_order.patch

e290929

nornagon requested a review from a team as a code owner January 16, 2020 00:41

nornagon added 3 commits January 15, 2020 16:45

drop old code for separate pdf_viewer_resources.pak

7d0203f

remove unused compenent_extension_resources.grd

bbd3a64

remove commented code

e06ae6e

nornagon commented Jan 16, 2020

View reviewed changes

nornagon added 3 commits January 16, 2020 13:36

fix build

2333bc2

lint

795d861

lint

41a3980

nornagon changed the title ~~[wip] feat: pdf viewer~~ feat: pdf viewer Jan 16, 2020

nornagon changed the title ~~feat: pdf viewer~~ feat: pdf viewer [wip] Jan 16, 2020

nornagon added 2 commits January 16, 2020 15:44

flag PluginResponseInterceptorURLLoaderThrottle behind build flag

57de32c

flag more stuff

4b20c5c

electron-cation bot removed the new-pr 🌱 PR opened recently label Jan 17, 2020

nornagon and others added 9 commits January 22, 2020 17:09

Merge remote-tracking branch 'origin/master' into extensions-pdf

a071b82

Merge remote-tracking branch 'origin/master' into extensions-pdf

ae293d9

enable_pdf_viewer = true

a78a517

generate function registrations

c645618

more tabs functions

44f0fec

[FIXME]: treat pdf plugin as origin-isolated

3627a7b

resources_private api

ccf21d5

fix gn check

7d44a5e

lint

85ed4b9

nornagon and others added 6 commits February 10, 2020 10:42

use electron resources instead of chrome resources

44af08a

Update use_electron_resources_in_pdf_util.patch

90d2072

patch instead of copy

7d6d87a

re-use chrome_url_request_util::LoadResourceFromResourceBundle

5d94e13

lint

2cd0f08

rely on the chrome DevToolsPageHandler

f9640ad

nornagon mentioned this pull request Feb 11, 2020

feat: enable pdf viewer #22131

Merged

trop bot added in-flight/9-x-y and removed target/9-x-y labels Feb 11, 2020

deepak1556 approved these changes Feb 11, 2020

View reviewed changes

nornagon added 5 commits February 12, 2020 13:58

prevent dcheck on context menu

5401c08

simplify webui hosts list

f350c3a

disable printing

b5ffd12

lint

e32b132

TODO about deduplication

761b5f4

nornagon merged commit d590f2e into master Feb 13, 2020

nornagon deleted the extensions-pdf branch February 13, 2020 00:39

nornagon added a commit that referenced this pull request Feb 13, 2020

feat: enable pdf viewer (#21794)

8d1077c

trop bot added merged/9-x-y and removed in-flight/9-x-y labels Feb 13, 2020

codebytere mentioned this pull request Feb 27, 2020

Native PDF rendering should be supported inside sub-frames and embed tags #9192

Closed

quanglam2807 mentioned this pull request May 8, 2020

feature: in-app PDF reader webcatalog/webcatalog-legacy#542

Closed

ronjouch mentioned this pull request Sep 10, 2020

[electron-10.x] PDF preview should be configurable / disablable nativefier/nativefier#1046

Open

Conversation

nornagon commented Jan 16, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of Change

Checklist

Release Notes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

trop bot commented Feb 11, 2020

Uh oh!

deepak1556 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nornagon Feb 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nornagon commented Feb 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

release-clerk bot commented Feb 13, 2020

Uh oh!

tomsontom commented Feb 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

exentrich commented Feb 24, 2020

Uh oh!

nornagon commented Feb 24, 2020

Uh oh!

rgilotra commented Mar 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

nornagon commented Jan 16, 2020 •

edited

Loading

nornagon Feb 11, 2020 •

edited

Loading

nornagon commented Feb 13, 2020 •

edited

Loading

tomsontom commented Feb 19, 2020 •

edited

Loading

rgilotra commented Mar 26, 2020 •

edited

Loading