Reuse the existing getOutputScale() machinery to render and/or rescale
thumbnail images to the native display resolution. Fixes blurry thumbnails on
HiDPI displays making it a lot easier to make out the content.
During A/B testing we found a significant preference (increased engagement
time, reduced downloads of original PDF for local viewing) for the version that
doesn't animate loading thumbnails.
Profiling shows that the transition effects hit at a pessimal time when the
compositor is busy rendering the main PDF page view, and rendering thumbnail
previews, causing the main scroll view to stutter. With the transition removed
scrolling is perceptibly smoother in Chrome and Firefox. We also hypothesize
that the transition effects added to a perception of slowness but presumably
the aforementioned stutter is the primary issue here.
- Remove a hack for Chrome on Windows because we do not run Chrome on the Windows bot anymore, so it added unneeded complexity.
- Merge nextTask and continueNextTask functions. nextTask did nothing more than calling cleanup. This change also allows us to remove the callback for that function.
- Remove unnecessary one-line functions.
Having recently spent some time staring at the PasswordPrompt, while fixing issue 6010, I felt that the current border style does not really give a good visual indication that the input field actually has focus.
The current appearance was first introduced in PR 3527; but I don't know if having a different border style in Overlay dialogs was intentional, or if it just "happened".
However, given the colour palette used in the viewer UI, I think that using the same border style for all .toolbarFields makes sense.
For passwords where the encoding already is correct, the conversion is a no-op.
Also, since `encodeURIComponent` might throw, we need to make sure that we handle that case too.
Fixes 6010.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1050040.
With this patch the file is completely readable, but given that the font is broken enough to be rejected by OTS the rendering differs slightly from Adobe Reader.
*Note:* the PDF file is sufficiently broken that even Adobe Reader complains about the font, *and* also about another more general issue.
*This patch addresses an issue I stumbled upon while working on rewriting the history implementation.*
Currently the `updateviewarea` UI event doesn't include the `location`, and in the event handler in viewer.js we instead reach into `PDFViewer` to retrieve it. Not only does this seem conceptually wrong, it also makes the `updateviewarea` event less useful in general since it's currently only possible to access the `location` if you have a reference to the `PDFViewer`.
To me, this simply appears to be an oversight in the implementation, hence this patch which adds `location` to the `updateviewarea` event. It also changes `location` to be a "private" property of `PDFViewer`.
