Do NOT save the temporary <canvas> element as `this.canvas`.
`PDFViewer.pages[i].canvas` appears to be used to generate the thumbnail
icons. Well, that's no justification for preventing GC of those
temporary <canvas> elements used during mozPrintCallback.
With a document consisting of 79 pages, this resulted in a 600-700MB
leaked memory.
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.
Before this commit there were two main issues:
- In small windows, the zoom controls visually floated above the page number
(e.g. 733px).
- In small windows, the (transparent) zoom container covered the go-to-page
input box, which prevented one from using the input field to quickly navigate
to a different page.
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
When <base href> is present, history.replaceState and
history.pushState behave inconsistent with relative URLs.
http://code.google.com/p/chromium/issues/detail?id=274024
Contrary to what one expect, passing '' as the URL parameter to
replaceState/pushState does not associate the currently active
URL with the history entry, but a path relative to <base href>.
To fix the issue, explicitly associate the current active URL
with the history's state.
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.
Tim van der Meij
Brendan Dahl
Jonas Jenwald
Rob Wu
mark-5
Srishti
Thor Larholm
maxidirienzo
Jonas
Nils Maier
Yury Delendik
Soumya Deb
Tim van der Meij