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.
In Blink-based browsers, there is a mismatch between document size and
paper size. Even if exactly the same values and unit are used, it is
possible that the printed results takes more pages than expected.
To solve the issue, the page size is set via @page size, and the canvas
and ancestor nodes are assigned a width+height of 100% (=relative to the
page). This change resolves bugs such as blank pages and split pages.
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.
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.
After PR #5282, the text highlighting in the Font Inspector is very hard to see against a white background. That seems to be an oversight from the mentioned PR, hence this patch fixes that.
As a consequence of merging #5221 it is more likely to have multiple
overlapping selection divs inside the text layer. Because each individual
element gets the selection style applied, the 30%opacity stacks, making a
60% bar visible where the overlap happens.
As proposed by @rocallahan, this can be fixed by making the selection
style solid and setting opacity for the overall layer.
I assume also that this should make the work for the renderer easier, but
was unable to bench it.
Currently in RTL locales, the loading indicator is placed such that it is in the way when entring a search term. Hence this patch moves it to the other side of the input field to fix this.
transformOrigin is set to 0% 0% in all cases. This adds extra memory
impact into the dom tree. It also involves the CustomStyles workaround
to determine the correct css rule for the browser.
By setting all vendor and standard variants in css, the rule is applied
without the dom memory overhead and without the minor computation
overhead to set the value.
Added an "InteractiveAnnotation" class to homogenize the annotations' structure (highlighting) and user interactions (for now, used for text and link annotations).
Text annotations:
The appearance (AP) has priority over the icon (Name).
The popup extends horizontally (up to a limit) as well as vertically.
Reduced the title's font size.
The annotation's color (C) is used to color the popup's background.
On top of the mouseover show/hide behavior, a click on the icon will lock the annotation open (for mobile purposes). It can be closed with another click on either the icon or the popup.
An annotation printing is conditioned by its "print" bit
Unsupported annotations are not displayed at all.
