Use streamsPrivate API when available.
When the API is not available, the extension will still work on
on http/https/file URLs, but not for POST requests or FTP.
As of writing, the Chromium project has still not whitelisted
the PDF Viewer extension in the Chrome Web Store.
(extension ID oemmndcbldboiebfnladdacbdfmadadm)
Request to whitelist PDF.js in Chromium:
https://code.google.com/p/chromium/issues/detail?id=326949
Opera 19 has whitelisted the PDF Viewer extension from
https://addons.opera.com/extensions/details/pdf-viewer/
(extension ID encfpfilknmenlmjemepncnlbbjlabkc)
(https://github.com/Rob--W/pdf.js/issues/1#issuecomment-32357302)
If you want to test the streamsPrivate feature in Chrome,
edit the build/extensions/manifest.json and add the "key" again
(see this commit for the value of this "key" field).
When a new incognito session is started, the onExecuteMimeTypeHandler event is
often not dispatched in time. Instead, it's triggered in the non-incognito profile.
This commit offers a work-around that allows new incognito instances to view PDF files.
This is needed for propagating the extension's permissions
to the extension's iframe, in the rare event that the PDF is
loaded in a sub frame, and the extension does not have access to the
top frame. For instance, when a http:-PDF file is embedded in a
local file, while "Allow access to local URLs" is disabled.
Note: Propagating permissions by inserting content scripts is an
undocumented feature (http://crbug.com/302548).
Whenever it breaks, the issue (cross-domain permissions for XHR)
can be solved by using a content script that gets the blob using
the XMLHttpRequest API, followed by `postMessage` (via transferables)
to efficiently pass the arraybuffer back to the PDF Viewer.
This method captures all application/pdf streams, loads the viewer
and passes the stream to the PDF.js viewer.
This commit shows a proof of concept using the chrome.streamsPrivate API.
Advantages of new method:
- Access to the response body of the original request, thus fewer
network requests.
- PDFs from non-GET requests (e.g. POST) are now supported.
- FTP files are also supported.
Possible improvements:
- Use declared content scripts instead of dynamic chrome.tabs.executeScript.
This allows the extension to render the viewer in frames when the
extension is disallowed to run executeScript for the top URL.
- Use chrome.declarativeWebRequest instead of webRequest, and replace
background page with event page (don't forget to profile the
difference & will the background/event page still work as intended?).
In Chromium extensions, the viewer's URL looks like this:
chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf
Furthermore, the PDF Viewer itself can also add something to the reference fragment:
chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://example.com/file.pdf#page=2
Consequently, it is difficult to copy a clean URL (e.g. for sharing over mail)
without having to tidy-up the URL manually.
This commit solves this issue by adding a button to the omnibox,
which shows the clean PDF URL on click.
Before commit:
chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf
After commit:
chrome-extension://EXTENSIONID/http://example/file.pdf
Technical details:
- The extension's background page uses the webRequest API to intercept
requests for <extension host>/<real path to pdf>, and redirect it to
the viewer's URL.
- viewer.js uses history.replaceState to rewrite the URL, so that it's
easier for users to recognize and copy-paste URLs.
- The fake paths /http:, /https:, /file:, etc. have been added to the
web_accessible_resources section of the manifest file, in order to
avoid seeing chrome-extension://invalid/ instead of the actual URL
when using history back/forward to navigate from/to the PDF viewer.
- Since the relative path resolving doesn't work because relative URLs
are inaccurate, a <base> tag has been added. This method has already
been proven to work in the Firefox add-on.
Notes:
- This commit has been cherry-picked from crx-using-streams-api.
- Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with
a bug in Chrome <=30
- In Chrome, getting the contents of a FTP file is not possible, so
there's no support for FTP files, even though the extension router
recognizes the ftp: scheme.
And use split incognito mode
Previous method:
- Rewrite content type to XHTML, followed by a content script
to cancel and replace the document with the viewer.
( https://github.com/mozilla/pdf.js/pull/3017 )
New method:
- Cancel loading of the document, followed by a redirect to the viewer
Disadvantage of new method:
- URLs are no longer "nice". This will be addressed by cherry-picking
a commit from the crx-using-streams-api branch.
Advantages of new method:
- Idle time is minimal. In some cases (with large documents),
it took too much time before the content script was activated.
During this period, the page looked blank, and the contents of
the PDF file were still retrieved and **discarded**.
With the new method, the idle time is minimal, because the request
is immediately cancelled.
- No FOUXEP (Flash of unhidden XML error page), because the XHTML
Content-Type hack is no longer used.
