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.
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...)
Two major issues:
1. Border/shadow around every page. Removed by adding "border:none".
2. Added "overflow:visible" (overrides "overflow:auto") in #viewContainer.
This solves two problems:
- It prevents scrollbars from appearing.
- Every "page" is automatically resized to fit on a printed page,
just like the Firefox.
To see what's wrong, here's a picture of how PDF.js rendered the pdf in
Chrome (using "Print to PDF" feature of Chrome):
https://robwu.nl/pdfjs/pdfjs-print-with-chromium-28.pdf
Successfully tested with Chrome 28 and Firefox 22.
Solves #3445
Tim van der Meij
Jonas
Nils Maier
Brendan Dahl
Rob Wu
Yury Delendik
Soumya Deb
Tim van der Meij
Srishti