In `viewer.js` we have code that ensures that the document is re-rendered on zooming and rotation. However, for `components` based viewers this might not work correctly, since there's currently no code which handles that.
Note that there is a good chance that this "just works" in many `components` viewers already, thanks to the `watchScroll` function.
The explanation is that zooming or rotation, most of the time, causes the viewer to change its (scrollable) size, thus triggering `PDFViewer_update` through `PDFViewer_scrollUpdate`.
However, in general there's no guarantee that this will actually work (since zooming and rotation doesn't necessarily change the size of the viewer for all documents), and requiring every viewer `components` implementer to provide methods for this doesn't seem like a great idea.
The reason that this code can be moved is that the `if (this.loading && page === 1)` check, in the `pagechange` event handler in viewer.js, is never satisfied since `this.loading` is not defined in that scope.
This *could* be considered a regression from PR 5295, since prior to that `this.loading` was using the `PDFViewerApplication` scope (or `PDFView` as it were).
However, I don't think that we need to fix that since we've been shipping this code in no less than *three* Firefox releases (uplifted in https://bugzilla.mozilla.org/show_bug.cgi?id=1084158), without breaking the world.
An explanation of why the `pagechange` code works, despite `this.loading === undefined`, is that `set currentPageNumber` (in `PDFViewer`) returns early whenever `this.pdfDocument` isn't set. This check is, for all intents and purposes, functionally equivalent to checking `PDFViewerApplication.loading`.
Hence we can move the page switching code into `PDFViewer`, and also remove `PDFViewerApplication.loading` since it's not used any more.
(The `this.loading` property was added in PR 686, which was before the current viewer even existed.)
*Note:* The changes in this patch should also be beneficial to the viewer `components`, since requiring every implementer to provide their own `pagechange` event handler just to get `PDFViewer.currentPageNumber` to actually work seems like an unnecessary complication.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1170063.
The bug only mentions the <kbd>Meta</kbd> key, but given that a similar situation can occur for <kbd>Ctrl</kbd>, it seemed reasonable to also handle that case in the same patch.
The only possible caveat with the patch is that because of the use of `shadow`, things won't work perfectly if either of the prefs are changed *while* the viewer is active. In this case a reload is required in order for it to work correctly, but given that the issue this patch fixes should be quite rare anyway, that seems OK.
Currently `PDFLinkService` requires access to a `PDFHistory` instance in order for it to work correctly (and to avoid errors). If we want `PDFLinkService` to be more useful in custom viewers, I don't think that we actually want to force it to have a `PDFHistory` instance.
Hence this patch, which contains a very simply approach to make `PDFHistory` optional.
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.
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.
*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.
This patch:
- Simplifies the way fields are passed to the document properties overlay
- Simplifies the way fields are filled internally in the document properties overlay
- Avoids passing a document properties reference to the secondary toolbar
- This patch uncomments a large portion of the Firefox specific code in viewer.js, by using a preprocessor "trick", to enable linting. Doing this actually uncovered some issues, e.g. variables defined multiple times.
- This patch also fixes a spelling error, `adobe pdfwritter` -> `abobe pdfwriter`, in the `KNOWN_GENERATORS` list used when reporting telemetry data in Firefox.
*Please note:* there's still some Firefox specific code that is commented out, but it's usually just one (or two) lines of code. Hence the risk that errors creep in should be much lower, compared to entire code-blocks.
This patch:
- Puts public methods at the top of the file
- Puts private methods below the public methods and marks them with an underscore
- Adds JSDoc comments to the class
- Adds setDocumentAndUrl to avoid having to handle that in `viewer.js`
This patch:
- Passes in a reference to the current PDFThumbnailViewer, which is used to ensure that the current thumbnail becomes visible when exiting PresentationMode.
- Changes the way that the event listeners for the contextmenu items are defined, to avoid passing in a reference to the SecondaryToolbar.
- Ensures that |supportsFullscreen| always returns a boolean.
Currently `supportsFullscreen` will, when the browser supports the fullscreen API, return e.g. `function mozRequestFullScreen()` instead of `true`.
- Simplifies the |click| handler code when PresentationMode is active.
This code has been obsolete ever since PR 2919 landed.
- Removes hack used to workaround a bug in WebKit browsers, which caused |mousemove| events to be fired when the cursor changed.
This was fixed close to a year ago, see http://code.google.com/p/chromium/issues/detail?id=103041.
This patch:
- Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons.
- Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them.
- Adds a utility function to `PDFViewerApplication` for requesting PresentationMode.
- Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
The line that this patch removes has been commented out since 2012 (!), see commit c8a6a9ba00.
Also, since the patch is trivial, I'm fixing the formatting of a comment to stop [GitHub from marking it with a red color](https://github.com/mozilla/pdf.js/blob/master/web/viewer.html#L394) (and IE from complaining).
After the refactoring in PR 5678, the B2G viewer now prints the following in the console:
```
ReferenceError: DownloadManager is not defined
```
This will obviously not matter once the B2G viewer is replaced with the new components-based one. But until that happens, I think it makes sense to just stub the class to suppress the error.
For consistency, this preference should be placed amongst the others. The current position is purely for "historical" reasons, since it was one of the first preferences that was added to the code.
Since the link is no longer valid, we should remove it from the comment.
(Using the Internet Archive, it seems that the contents of that page was basically identical to the PDF specification.)
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.
This patch also rearrange the order of the references to the DOM elements of the predefined zoom values, in viewer.js, to correspond with the element order in the current viewer UI. (The previous ordering is a leftover from the previous viewer UI.)
Instead of trying to hack around various browser defects, let's just disable PresentationMode in the affected browsers. This patch:
- Disables PresentationMode in IE11+ when the viewer is embedded; fixes 4711.
Set transformation matrix in (polyfilled) mozPrintCallback when a scale
is applied. Removed _scaleX and _scaleY in favor of _transformMatrix to
emphasize that the caller MUST ensure that the state of the matrix is
correct before `addContextCurrentTransform` is called.
From reading IRC scrollback, it became clear that having to manually call `PDFFindController.resolveFirstPage` in order for the find functionality to work isn't particulary good. Hence this PR, which moves that code into `PDFViewer.setDocument` to make life easier for third-party implementations.
See "Case-insensitive language comparisons per RFC 4646"
https://github.com/fabi1cazenave/webL10n/pull/51
Removed the "patch" in compatibility.js and fixed the bug in webL10n,
because the logic belongs to webL10n instead of PDF.js.
The immediate motivation for this patch is that Chrome 40 converts
navigator.language to lower case: https://crbug.com/454331
We can pass it in using the options object. Note that that this also avoids creating a DownloadManager object for each separate link (instead, having only one is enough).
This includes an optimization to zero the height and width of existing thumbnail canvases, when they are removed and recreated during rotation of the document. (Credit goes to nnethercote, who initially found this in PR 4920.)
In old versions of the viewer, anchor links were used to be able to scroll a page into view. Since we for quite some time have had a `scrollIntoView` function which handles this, the anchor links are no longer necessary and I believe that they can be removed. Doing so will reduce the total number of DOM elements in the viewer.
For most documents this patch will probably not make much of a difference performance wise, but for very long (1000+ pages) documents this could help performance especially on lower powered hardware.
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.
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.
