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.
The logic for the hand tool is implemented in a separate project,
maintained at https://github.com/Rob--W/grab-to-pan.js
Integration notes
- Added toggle as an entry under the Secondary toolbar
- Added shortcut "h" to toggle hand tool (to-do: document this in wiki
after merge). This shortcut is also used in Adobe's Acrobat Reader.
To-do: localizations for:
hand_tool_enable.title=
hand_tool_enable_label=
hand_tool_disable.title=
hand_tool_disable_label=
To-do (wish): persistence of hand tool preference, preferably a global setting.
secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
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.
This shim does the following:
1. Intercept window.print()
2. For a window.print() call (if allowed, ie. no previous print job):
1. Dispatch the beforeprint event.
2. Render a printg progress dialog.
3. For each canvas, call mozPrintCallback if existent (one at a time, async).
4. During each mozPrintCallback callback, update the progress dialog.
5. When all <canvas>es have been rendered, invoke the real window.print().
6. Dispatch the afterprint event.
The shim is not included in Firefox through the preprocessor.
Keyboard shortcuts (Ctrl/Cmd + P) are intercepted and default behavior
(i.e. printing) is prevented, and the steps for window.print() are run.
window.attachEvent is used, in order to cancel printing in IE10 and
earlier (courtesy of Stack Overflow - http://stackoverflow.com/a/15302847).
Unfortunately, this doesn't work in IE11 - if Ctrl + P is used, the
print dialog will be shown twice: Once because of Ctrl + P, and again
when all pages have finished rendering.
This logic of this polyfill is not specific to PDF.js, so it can also
be used in other projects.
There's one additional modification in PDF.js's viewer.js: The printed
<canvas> element is wrapped in a <div>. This is needed, because Chrome
would otherwise print one canvas on two pages.
If focused element is a textarea, viewer should not process keyboard shortcuts (as it does with input and select elements) because while writing on a textarea, if you press k,p,l, or n, the viewer scrolls next/prev page and the letter is not added to the textarea (eg. in my case I had a viewer displaying a product specs in PDF and a "request a quote" form at it's right, the form had a textarea field and users complains that they couldn't write in it, after checking it, I've realized it was this particular issue and fixd it with the change I'm commiting.
