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.
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`.
*This is a follow-up to PR 5966.*
Now that https://bugzilla.mozilla.org/show_bug.cgi?id=1151931 has landed, we're unfortunately in a situation where Firefox warns about `unreachable code after return statement` multiple times when using the PDF.js code in `node make server` mode.
I'm really sorry about the churn in this code!
However I don't think it's a good idea to let Firefox continue to printing these warnings in the console, since it increases the risk of missing actual errors.
Yury Delendik
Brendan Dahl
Tim van der Meij
Mike Corbin
Jonas Jenwald
Xiliang Chen
Fabian Lange
Martin Heller
David Flanagan