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
== -> ===
Before:
- Firefox's buttons looks OK
- Chrome (quirks mode): Buttons were aligned to the bottom (too much)
- Chrome (standards mode): Buttons were aligned to the top (too much)
- Opera/IE/Safari: Like Chrome (standards): Buttons too high
(Too high = Compare the other buttons to the rightmost button)
After:
- Firefox's button positions didn't change at all
- All buttons are aligned at the same level, across all browsers
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.
Yury Delendik
Mack Duan
Jakob Miland
Jonas
Kalervo Kujala
Brendan Dahl
vyv03354
mete0r
Rob Wu
Inkbug
Simon Tatham
waddlesplash
Ofir