Proposal: Remove PDF viewer, print preview and extension support from the Alloy runtime

[magreenblatt]

Original report by me.

---

This proposal is to remove support for the PDF viewer extension, print preview (which uses the PDF viewer) and the extension system from the Alloy runtime. They will remain supported by the Chrome runtime (see issue #2969).

In order to support PDF viewer functionality the Alloy runtime must implement portions of the Chrome extension system (see issue #1947). This implementation involves a substantial and recurring maintenance cost, and there are currently a number of open bugs that are not being actively addressed. Additionally, the current Alloy runtime extension system implementation is not particularly useful as a standalone feature since it only implements a small subset (see chrome://extensions-support) of the documented Chrome extension APIs.

[magreenblatt]

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).

---

Does Chrome runtime support shared GPU textures? (PR #285). Asking, because I have a use case for displaying PDFs using hardware rendering.

[magreenblatt]

@{557058:93489ef7-acae-448f-9840-15ddb0beb530} Off-screen rendering support (including shared GPU textures) is not currently in scope for the initial Chrome runtime effort, but it may be possible to add at some future point.

[magreenblatt]

To clarify the above comment, usage of the Ozone layer (like Chrome headless; see also issue #2296 and issue #2804) would likely be the best way to implement shared textures with the Chrome runtime.

[magreenblatt]

Original comment by Alex Maitland (Bitbucket: a-maitland).

---

@{557058:2f2a2aee-b500-4023-9734-037e9897c3ab} How likely is it that we’ll end up with an OSR implementation that doesn’t have a PDF viewer?

[magreenblatt]

@a-maitland It’s a possibility, in which case those applications would need to download the PDF file or convert them to HTML.

[magreenblatt]

Original comment by Alex Maitland (Bitbucket: a-maitland).

---

Understood.

Does the migration of pdfium away from ppapi set a timeline for the removal of the PDF viewer?

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

[magreenblatt]

@a-maitland Thanks for the link. That migration effort could become the removal deadline, depending on the scope of associated changes. Alternately, it could be very good for us if the PDF viewer becomes part of the content layer as suggested in this comment from the associated design doc.

[magreenblatt]

We won't be removing the PDF viewer at this time.

[magreenblatt]

• changed state from "new" to "closed"

[magreenblatt]

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).

---

I’m thinking of using PDF.js instead of built-in PDFium in one of my projects and wondering about compatibility and performance differences. If anyone tried that or other JavaScript based solution to render PDF files and could share experience that would be great.

‌

[magreenblatt]

Original comment by Johann Scheiterbauer (Bitbucket: Phylanx, GitHub: Phylanx).

---

We use our CEF integration to provide HTML content of our other departments.
If I remember correctly, one of them uses pdf.js to visualize PDFs.

We had some performance/memory issues but they were gone with the newes pdf.js version.