Now that [bug 649849](https://bugzilla.mozilla.org/show_bug.cgi?id=649849) has been fixed, adding support for `-moz-appearance: none`, the arrow is now too close to the text in the zoom box. This is currently only an issue in Nightly, but assuming the patch doesn't get backed out, this will soon affect all versions of Firefox.
The only simple solution I could find seems to be removing `*-appearance: none` rules from the CSS. I haven't been able to find any easier solutions that still looks the same with/without bug 649849.
Currently if you manage to e.g. open the console (with <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>K</kbd>) before the viewer is initialized, the following will be printed in the console: `TypeError: pdfViewer is null`.
This doesn't cause any actual errors, but nevertheless it seems like something we should avoid.
Followup to PR 5413.
When a search term isn't found, the background color of the findInput is supposed to change (to red). This is currently not working as intended, because the CSS rule is not being applied correctly. (It seems that this broke in PR 2208.)
This patch also changes the background color to match the one used in the native Firefox findbar, since the old color seemed a bit too pink.
Since `preferenceSidebarViewOnLoad` is an enumeration value, it seems better to initialize it with the default one instead of a boolean.
`preferencesPdfBugEnabled` uses a superfluous "s", which is a typo I made when I introduced it.
Even after PR 5359, switching to/from Presentation mode is still sluggish and I'm still seeing `too much recursion` printed in the console.
I've managed to track down the issue to line https://github.com/mozilla/pdf.js/blob/master/web/page_view.js#L371. It appears that for this particular case, we actually *need* to set `noScroll = true` when calling the `_setScale` function. (Note that it only applies to *this* line, and not to Presentation mode in general.)
Given the amount of refactoring done to the viewer, I'm not sure what the best way to fix this would be. However I'm submitting this patch as an easy workaround for now, but we should probably refactor this to avoid calling a "private" method directly.
