Restrict the scrollbar hack to the keycode for "spacebar",
since the bug only occurs in Firefox with spacebar.
Keyboard navigation is only activated for the spacebar if
the currently focused element is not a button.
These lines were introduced in 612f59aa10
when the only shortcuts were +/-/=/0 (to change zoom level).
Back then, when the input fields were focused, using these keys would
add these unwanted characters to the input field and change the zoom
level of the viewer. Having both operations at the same time was an
undesired event, so a check was inserted, to ignore shortcuts when
the toolbar is focused.
The #toolbar element doesn't exist any more, so these lines are obsolete.
The PDF Viewer will always be rendered directly from the extension,
so checking "origin == chrome-extension:/.." is not needed any more.
( since edd4bae903 )
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.
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.
The ArrayBuffer holding the data might be over-sized in case the
data length was not known during the transfer, e.g. when using a
Content-Encoding other than `identity` or when using a
Transfer-Encoding.
Only the view into the buffer has the correct length then, hence
always use the view directly when creating the blob URI for the
download, instead of the over-sized underlying buffer.
Closes GH-3627
Closes GH-3634
pdfHandler-local.js references the isPdfDownloadable function from
pdfHandler.js, but the function didn't expect that the responseHeaders
property was absent. Added a check to prevent a runtime error when a
local file is displayed in a frame, and show local PDF files again.
Local files are rendered on the chrome-extension:-protocol. The previous
method of getting the PDF URL was incorrect, this has been fixed as well.
Move inline event handlers to viewer.js to comply with a
Content-Security-Policy where directive "unsafe-inline" is not set.
Change textarea.rows = <number of newlines> to
textarea.style.height = textarea.scrollHeight.
(The former is extremely unreliable; consider long lines...)
Declares the URL variable globally. If the feature is not
supported, the variable will still be declared, but have the
"undefined" value.
Supported by:
- Firefox 4
Firefox 21 in Web worker
- Chrome 8 (prefixed as webkitURL), 23+ unprefixed
Chrome 10 (prefixed as webkitURL) in Web Worker, 23+ unprefixed
- Opera 15
Opera 15 in Web Worker
- Internet Explorer 10
Internet Explorer 11 in Web Worker
- Safari 6 (prefixed as webkitURL)
Safari 6 (prefixed as webkitURL) in Web Worker
This feature relies on URL.createObjectURL, which is supported by
- Firefox 4
- Chrome 8
- Opera 15
- Internet Explorer 10
If the feature is missing, it falls back to downloading from the server.
The environment-specific code are put in ifdef's. Two methods are
defined:
- noData
This function is used as a fallback in case of failure, it triggers
a download directly from the server.
- triggerSaveAs(String url, optional String blob)
This function attempts to show a Save As dialog for a given URL.
It attempts to use the a.download attribute, if available, and
falls back to window.open(<url>, '_parent') if unavailable.
See also http://caniuse.com/download
The Chrome extension activates PDF.js by inserting the script tags
in a document whose URL and location origin is identical to the PDF
file.
Because of this, the path './images/' was resolved relatively to the
location of the PDF file instead of the extension.
To fix this, the IMAGE_DIR constant is moved outside the local scope,
to allow extensions/chrome/insertviewer.js to override the value.
Originally, the IMAGE_DIR variable was a global variable, but commit
f8f4b3f45d moved the global variable
to the local scope, causing the extension to malfunction.
Impact: low, the only consequence is that some rarely used images
were not visible.
Trivial test:
At the center of page 2, the annotation icon
(images/annotation-comment.svg) should be visible:
http://linorg.usp.br/CTAN/macros/latex/contrib/pdfcomment/doc/pdfcomment.pdf
Fix download button for top frames and sub frames
When PDF.js is the top frame, and the PDF URL is identical to
the top URL, download would fail. Fixed by adding a ? or & in these
cases.
When PDF.js is embedded in a frame from a different origin, download
would fail because window.open(url, '_parent') is ignored.
Fixed by using a.click() when available.
a.click() works in Chrome 25, Firefox 19, Opera 12.00 and IE 8.
Safari 5.1 does not support a.click()
Use a.download if available + documentation
Previously, when the XHTML doctype + header is active, checks
would fail because a <div>'s tag name is "div" instead of "DIV".
document.activeElement does not exist in Chrome for XHTML documents
== -> ===
The previous default in the absence of provided coordinates was the
bottom left, so that if you followed a PDF link annotation with a
destination of [page /XYZ null null null] then you would see a gutter
followed by the page _after_ the intended one, because pdf.js had
carefully aligned the lower left corner of the target page with the
top of the window.
As part of this change we allow missing x,y parameters in URLs with a
&zoom= parameter to propagate nulls into pageViewScrollIntoView
instead of being replaced with zero in pdfViewSetHash, so as to do
this substitution in one place.
summary: create a new Exception class for missing PDF's, use it in place of generic
add new MissingPDFException to util.js
handle MissingPDF in api.js
handle MissingPDF in viewer.js, using new missing_file_error message
add new missing_file_error to l10n/en-US/viewer.properties
send MissingPDF from WorkerMessageHandler's loadDocument
send MissingPDF from GetDocRequest handler
