"text/javascript" is not a correct MIME type (the correct one is
"application/javascript") but it's not even needed; all browsers default
to the correct type and treat it as executable JS when type is ommited.
Since not all browsers recognize the "application/javascript" MIME type
the only way to both stay compliant and to support all popular browsers
is to omit the type. It's also shorter this way.
http://crbug.com/280464 has been resolved, so we can now use redirectUrl at
onHeadersReceived.
For backwards-compatibility, the code for the original method has not been
removed, and a feature detection script was added that detects whether the
desired feature is available.
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.
Also:
- Use webNavigation.getAllFrames to find out whether the navigation has
already started. This is (at least) needed for top-level navigation to
a stream. The webNavigation.onErrorOccurred event has become obsolete,
and has been removed.
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?).
Yury Delendik
Gijs Kruitbosch
Jonas Jenwald
Michał Gołębiowski
Rob Wu
Adam Dane [:hobophobe]
Tim van der Meij
Samuel Chantaraud
Rob Wu
Brendan Dahl
Mitar
Gabriele Svelto
fkaelberer