This is a regression from ddd3c8fc2f, which prevents changing pages in the Stepper.
(Apart from fixing the bug, for the sake of consistency, I also removed one instance of `parseInt`.)
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 when an exception is thrown, we try to reject `workerReadyCapability` with multiple arguments in src/core/api.js. This obviously doesn't work, hence this patch changes that to instead reject with the exception object as is.
In src/core/worker.js the exception is currently (unncessarily) wrapped in an object, so this patch also simplifies that to directly send the exception object instead.
"This commit fixes the issue that a focused element cannot lose
focus when the draggable element is clicked."
https://github.com/Rob--W/grab-to-pan.js/commit/11c368f97cebe19
Steps to reproduce/verify:
1. Enable the hand tool (e.g. by using the H shortcut)
2. Click on the Page number input.
3. Click or drag the PDF canvas.
4. Observe that the page number input is still focused.
Consequently, the hand tool cannot be disabled using the H shortcut.
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.
This change makes scrolling noticeably smoother on files with many
single-char text divs, such as the one in #1045. The trade-off is that
the visual appearance of text selection in such documents is slightly
worse, because more text divs overlap.
This change also uses `scaleX(N)` instead of `scale(N, 1)`. This might
be marginally more efficient in terms of JS string concatenation.
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.
As requested in #5178, this change debounces the scroll events.
The reason for doing so is that browsers can event-storm especially on
scroll, communicating hundreds of subpixel changes.
The main reason for this resulting in poor performance is that on each
scroll event `scrollTop` was queried, which forces layouting.
This change will use `requestAnimationFrame` to make sure the browser can
allocate enough time to other tasks. The delay is however quite small, thus
the reduction in executions is less noticeable. Modern browsers however utilize
`requestAnimationFrame` to smoothen out rendering.
The data-font-name attribute of textLayer divs are only used by the Font
Inspector. This change ensures they are only present when the pdfBug
tools are enabled.
With the changes made in PR 5169 to enable quicker display of the File size, `setFileSize()` can now be called during file loading. This function parses *and* localizes the file size, where the l10n is a synchronous operation.
This patch:
* Re-factors `setFileSize()` to *only* update `rawFileSize`, and moves parsing and fetching of the l10n string to a separate method that isn't called until the Document Properties dialog is actually opened.
* Adds a couple of checks to make sure that `rawFileSize` is set to a positive number.
* Removes the `fileName` and `fileSize` properties. Since they are parsed every time the Document Properties dialog is opened, it doesn't seem necessary to cache them.
Since the "Previous/Next Page" buttons are disabled when the first/last page is active, I think that for the sake of consistency the "Go to First/Last Page" should behave the same way.
Currently the File size field in the Document Properties dialog isn't set until `PDFView.pdfDocument.getDownloadInfo()` is resolved. If the Document Properties dialog is opened while a PDF file is loading with range requests, this leads to the less desirable situation where all fields *except* File size are available.
In cases where `PDFView.open()` is called with the `args` parameter defined, and `args` contains the property `length`, we actually know the File size when the PDF file begins to load. (This is usually the case when ranged loading is used in the Firefox addon/built-in version.)
Hence we can use `args.length` to set the File size immediately when `PDFView.open()` is called, resulting in a better user experience.
This change improves the text layer creation of "normal" text heavy documents.
It changes 2 things:
* If the text element is not rotated, it will neither calculate nor apply a
textTransform: rotate(0deg) to the text layer element.
* For scaling the text layer div, the context will measure the width of the
text in the given font. For many text documents the font changes seldom.
If the font stays the same, the context does not need to be set to a new font
especially avoiding the temporary creation of the same font string over and
over again.
QtWebKit does not support file:-URLs in Web Workers.
To solve this issue, I'm loading file:-URLs in the main thread
for generic builds. file:-URLs load relatively quick, so there
is no need for sophisticated load progress notifications.
The absence of this property caused the following error in PDFView.download:
Cannot read property 'split' of undefined
This property was unset when the PDF was loaded through a typed array instead
of a URL. With the fix, the file name will default to "document.pdf", as
defined by getPDFFileNameFromURL in web/ui_utils.js
The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.)
This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
Currently (at least in Firefox) when the HOME/END keys are pressed, this will trigger unnecessary rendering of pages that lay between the current page and the first/last page. Avoid this by going straight to the first/last page instead.
"text/javascript" is not a correct MIME type (the correct one is
"application/javascript") but it's not even needed; all browsers default
to the correct type and treat it as executable JS when type is ommited.
Since not all browsers recognize the "application/javascript" MIME type
the only way to both stay compliant and to support all popular browsers
is to omit the type. It's also shorter this way.
