Commit Graph

3188 Commits

Author SHA1 Message Date
Jonas Jenwald
8eed0b9145 Report "pageInfo" telemetry once, rather than for each rendered page
Reporting telemetry, in Firefox, includes using `JSON.stringify` on the data and then sending an event to the `PdfStreamConverter.jsm`-code.
In that code the event is handled and `JSON.parse` is used to retrieve the data, and in the "pageInfo"-case we'll then proceed to ignore everything except *the first* such event; see https://searchfox.org/mozilla-central/rev/24fac1ad31fb9c6e9c4c767c6a7ff45d226078f3/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#509-514

All-in-all, sending the "pageInfo" telemetry for each rendered page is thus unnecessary and this patch makes the viewer send it only *once* instead.
2021-11-11 12:36:06 +01:00
Brendan Dahl
4ee906adf4
Merge pull request #14209 from Snuffleupagus/issue-14205
[Google Chrome] Ensure that `markedContent` spans are placed in the top-left corner (issue 14205)
2021-11-09 07:59:14 -08:00
Tim van der Meij
891f21fba6
Merge pull request #14245 from Snuffleupagus/PDFPageViewBuffer-class
Convert `PDFPageViewBuffer` to a standard class, and use a `Set` internally
2021-11-07 14:37:33 +01:00
Jonas Jenwald
13ef763222 [Google Chrome] Ensure that markedContent spans are placed in the top-left corner (issue 14205)
*This is a tentative patch, since we unfortunately cannot easily test it (as far as I can tell).*

In Firefox this (obviously) works as-is, but in Google Chrome the `markedContent` spans are inserted within the regular text-content (in the DOM) and with non-zero heights.
2021-11-07 11:01:35 +01:00
Jonas Jenwald
12d41bcba4 Prevent mobile devices from interfering with the textLayer-elements (issue 14243)
*This is a tentative patch, since I don't have the necessary hardware to test it.*

See https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjust, which is currently ignored in Firefox.
It seems overall safer, and more future-proof, to simply add this to the *entire* `textLayer` rather than its individual elements.
2021-11-06 11:39:43 +01:00
Jonas Jenwald
a774707e31 Remove the moveToEndOfArray helper function, since it's unused
With the previous patch, this helper function is no longer used and keeping it around will simply increase the size of the builds.
This removal is purposely done *separately*, to make it easy to revert the patch in the future if this helper function would become useful again.
2021-11-06 10:19:17 +01:00
Jonas Jenwald
f55bf42398 Convert PDFPageViewBuffer to use a Set internally
This relies on the fact that `Set`s preserve the insertion order[1], which means that we can utilize an iterator to access the *first* stored view.

Note that in the `resize`-method, we can now move the visible pages to the back of the buffer using a single loop (hence we don't need to use the `moveToEndOfArray` helper function any more).

---
[1] This applies to `Map`s as well, although that's not entirely relevant here.
2021-11-06 10:19:17 +01:00
Jonas Jenwald
0eba15b43a Convert PDFPageViewBuffer to a standard class
This patch makes use of private `class` fields, to ensure that the previously "private" properties remain as such.
2021-11-06 10:19:17 +01:00
Jonas Jenwald
fe205efd8d Add a couple of basic unit-tests for PDFPageViewBuffer
The `PDFPageViewBuffer`-code is very important for the correct function of the viewer, but it's currently not tested at all.
While the `PDFPageViewBuffer` is obviously intended to be used with `PDFPageView`-instances, it only accesses a couple of `PDFPageView` properties/methods and consequently it's fairly easy to unit-test this code with dummy-data.

These unit-tests should help improve our confidence in this code, and will also come in handy with other changes that I'm working on (regarding modernizing and re-factoring the `PDFPageViewBuffer`-code).
2021-11-05 19:43:20 +01:00
Jonas Jenwald
e78e4e72bf Further modernize PDFThumbnailViewer.scrollThumbnailIntoView
The way that we're currently handling the last-`id` is very old, and there's no longer any good reason to special-case things when only one thumbnail is visible.
Furthermore, we can also modernize the loop slightly by using `for...of` instead of `Array.prototype.some()` when checking for fully visible thumbnails.
2021-11-03 21:13:47 +01:00
Jonas Jenwald
6323f8532a Let getVisibleElements return a Set containing the visible element ids
Note how in `PDFPageViewBuffer.resize` we're manually iterating through the visible pages in order to build a Set of the visible page `id`s. By instead moving the building of this Set into the `getVisibleElements` helper function, as part of the existing parsing, this code becomes *ever so slightly* more efficient.

Furthermore, more direct access to the visible page `id`s also come in handy in other parts of the viewer as well.
In the `BaseViewer.isPageVisible` method we no longer need to loop through the visible pages, but can instead directly check if the pageNumber is visible.
In the `PDFRenderingQueue.getHighestPriority` method, when checking for "holes" in the page layout, we can also avoid some unnecessary look-ups this way.
2021-11-03 21:13:44 +01:00
Tim van der Meij
2ac6c939a5
Merge pull request #14225 from Snuffleupagus/render-better-holes-check
Avoid doing unnecessary checks, when pre-rendering page layouts with "holes" (PR 14131 follow-up)
2021-11-03 19:48:37 +01:00
Tim van der Meij
c68dc03be6
Merge pull request #14221 from Snuffleupagus/pr-12870-followup
Use `BaseViewer.previousPage` more in the default viewer (PR 12870 follow-up)
2021-11-03 19:44:12 +01:00
Jonas Jenwald
ab5f4a3e5e Avoid doing unnecessary checks, when pre-rendering page layouts with "holes" (PR 14131 follow-up)
*Sometimes I'll hopefully learn to optimize my code directly when writing it, rather than having to do multiple clean-up passes; sorry about the churn here!*

For most page layouts there won't be any "holes" in the visible pages (or thumbnails), and in those cases it'd obviously be preferable not having to repeat any checks of already rendered pages.
Rather than only checking the "distance" between the first/last pages, we can instead compare the theoretical number of pages (between first/last) with the actually visible number of pages instead. This way, we're able to better detect the "holes"-case and can skip unnecessary parsing in the common case.
2021-11-03 09:40:39 +01:00
Jonas Jenwald
292a715c1c Use optional chaining to simplify PDFViewerApplication.store accesses in various event handlers
This way we no longer need the intermediate variables.
2021-11-02 12:00:57 +01:00
Jonas Jenwald
d6e8b8fbc1 Use BaseViewer.previousPage more in the default viewer (PR 12870 follow-up)
I missed this one spot in PR 12870, when converting the other cases in the "keydown" event handler. However, given that it only matters in PresentationMode and/or when "page-fit" zooming is enabled, this oversight shouldn't have had any user-observable impact (but we should fix it nonetheless).
2021-11-02 11:48:18 +01:00
Jonas Jenwald
f4e88b0a57 [Firefox] Handle errors if loading failed before the "supportsRangedLoading" message was sent (bug 1732141)
This is a follow-up to PR 10675, since there I completely overlooked that we also need to handle the case where a PDF document has *failed* to load when the "supportsRangedLoading" message is sent to the viewer.
2021-11-01 17:50:49 +01:00
Jonas Jenwald
8c70258065
Merge pull request #14182 from calixteman/richtext
Support rich content in markup annotation
2021-10-31 14:41:56 +01:00
Calixte Denizet
cf8dc750d6 Support rich content in markup annotation
- use the xfa parser but in the xhtml namespace.
2021-10-31 13:44:51 +01:00
Tim van der Meij
317e4dd146
Merge pull request #14204 from Snuffleupagus/rm-shadowViewer
Remove the `shadowViewer` used with Page scrolling
2021-10-30 12:37:30 +02:00
calixteman
2c0bbaf208
Merge pull request #14153 from catherinemds/xfa-link
Fix XFA links (bug 1735738)
2021-10-29 11:06:00 -07:00
Catherine
db0b3cda8b XFA - Fix xfaLink class to make links work (bug 1735738)
There were some links not working in some XFA files,I realized that the anchor tag that contains the link has an inline display and couldn't receive any height, solved this by adding a "position: absolute". Tested with two different files in Firefox Nightly and Chrome and now all links are working perfectly fine. Added reftest to avoid future regressions
2021-10-29 11:39:33 -04:00
Jonas Jenwald
c18df2c61f Remove the shadowViewer used with Page scrolling
The only reason for using a `DocumentFragment` in the first place, originally added in PR 8724, was to prevent errors in the `PDFPageView`-constructor. However, we should be able to simply make its `container`-option *optional* instead, since it's not being used for anything else in the class.

Note that pre-rendering still works correctly in my testing, and given that the `BaseViewer` keeps references to all `PDFPageView`-instances (via its `_pages` Array) it also shouldn't be possible to "lose" any pages/canvases this way.
2021-10-28 13:48:15 +02:00
Tim van der Meij
6f3700b393
Merge pull request #14191 from Snuffleupagus/viewer-empty-pageLabels
Ignore pageLabels, in the viewer, when they're all empty
2021-10-27 20:01:45 +02:00
Jonas Jenwald
66c26d70d4 Ignore pageLabels, in the viewer, when they're all empty
Unfortunately there exist PDF documents where all pageLabels are empty strings, see e.g. http://www.cs.cornell.edu/~ragarwal/pubs/blk-switch.pdf (taken from an old issue), which result in the pageNumber-input being completely blank. That doesn't seem very helpful, and this patch simply extends the approach used to ignore pageLabels that are identical to standard page numbering.
2021-10-25 16:11:04 +02:00
Jonas Jenwald
2c779a8fbe [Regression] Prevent breaking errors when opening a new document in the GENERIC viewer (PR 14158 follow-up)
In the GENERIC viewer, e.g. when dragging-and-dropping a new PDF document which automatically opens the outline, there can now be breaking errors in the `{BaseViewer, PDFThumbnailViewer}.#getScrollAhead` methods since there's no visible pages/thumbs during loading; sorry about the breakage!
2021-10-25 14:27:24 +02:00
Jonas Jenwald
c85cd80b1b Remove unnecessary pageLabel length-check in the viewer
Given how the pageLabel array is defined, see 1ab9a6e36e/src/core/catalog.js (L627), it shouldn't be necessary to check the length in the viewer.
2021-10-25 13:25:34 +02:00
Jonas Jenwald
3dc738c4c8 Slightly simplify the isThumbnailViewEnabled check in PDFRenderingQueue.renderHighestPriority 2021-10-23 19:59:14 +02:00
Jonas Jenwald
91692a20d1 Skip the first/last visible pages pre-rendering page layouts with "holes" (PR 14131 follow-up)
This was a stupid oversight on my part, since the first/last visible pages have obviously already been rendered at the point when we're checking for any potential "holes" in the page layout.
While this will obviously not have any measurable effect on performance, we should nonetheless avoid doing completely unnecessary checks here.
2021-10-23 19:15:37 +02:00
Jonas Jenwald
24b7fb20ef Improve pre-rendering at the start/end of the document
This is a very old "issue", which has existed since essentially forever, and it affects all of the available scrollModes. However, in the recently added Page-mode it's particularily noticeable since we use a *simulated* scroll direction there.

When deciding what page(s) to pre-render, we only consider the current scroll direction. This works well in most cases, but can break down at the start/end of the document by trying to pre-render a page *outside* of the existing ones. To improve this, we'll thus *force* the scroll direction at the start/end of the document.

*Steps to reproduce:*

 0. Open the viewer, e.g. https://mozilla.github.io/pdf.js/web/viewer.html
 1. Enable vertical scrolling.
 2. Press the <kbd>End</kbd> key.
 3. Open the devtools and, using the DOM Inspector, notice how page 13 is *not* being pre-rendered.
2021-10-23 19:15:37 +02:00
Jonas Jenwald
7216511fbf Convert TempImageFactory to a class, using static fields/methods
Please refer to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields
2021-10-22 22:01:19 +02:00
Tim van der Meij
38e5360533
Merge pull request #14162 from brendandahl/indent-stepper
Indent the stepper on save/restore.
2021-10-22 21:17:36 +02:00
Brendan Dahl
2e56369f79 Indent the stepper on save/restore.
Makes it easier to debug and visualize the graphics
state changes in the debugger.
2021-10-22 10:30:32 -07:00
Tim van der Meij
ce86f9dfdd
Merge pull request #14155 from mozilla/revert-13314-color-theme
Revert "For mozcentral use Firefox color theme instead of system theme." since `-moz-toolbar-prefers-color-scheme` was removed
2021-10-19 19:29:20 +02:00
Jonas Jenwald
aae8a21286 Revert "For mozcentral use Firefox color theme instead of system theme." since -moz-toolbar-prefers-color-scheme was removed
Reverts mozilla/pdf.js#13314, see https://groups.google.com/g/firefox-dev/c/vajhbYKDpPM

Given that `-moz-toolbar-prefers-color-scheme` was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1736038, unless we fix this before the next PDF.js update in mozilla-central we'll thus break dark mode in the Firefox built-in PDF Viewer.
2021-10-17 12:29:25 +02:00
Jonas Jenwald
00720d059a [api-minor] Include the /Lang-property in the documentInfo, and use it in the viewer (issue 14110)
*Please note:* This is a tentative patch, since I don't have the necessary a11y-software to actually test it.

To avoid having to add a new API-method just for a single string, I figured that adding the new property to the existing `documentInfo`-data (accessed via `PDFDocumentProxy.getMetadata` in the API) will hopefully be deemed acceptable.
2021-10-16 14:27:47 +02:00
Jonas Jenwald
fa8c0ef616 [api-minor] Change PDFFindController to use the "find"-event directly (issue 12731)
Looking at the code, I do have to agree with the point made in issue 12731 about it being unexpected/unhelpful that the `PDFFindController.executeCommand`-method isn't directly usable with the "find"-event.
The reason for it being this way is, as so often, for historical reasons: The `executeCommand`-method was added (just) prior to the introduction of the `EventBus` in the viewer.

Obviously we cannot simply change the existing `PDFFindController.executeCommand`-method, since that'd be a breaking change in code which has existed for over five years.
Initially I figured that we could simply add a new method in `PDFFindController` that'd accept the state from the "find"-event, however after thinking about this and looking through the use-cases in the default viewer I settled on a slightly different approach: Let the `PDFFindController` just listen for the "find"-event (on the `EventBus`-instance) directly instead, which also removes one level of (unneeded) indirection during searching in the default viewer.

For GENERIC builds of the PDF.js library, the old `PDFFindController.executeCommand`-method is still available with a deprecation warning.
2021-10-16 10:36:22 +02:00
Jonas Jenwald
cd22c31752 Fix the remaining Promise.resolve(undefined) cases
Many years ago now there were some `Promise` implementations that had issues resolving with an *implicitly* `undefined` value. That should no longer be the case, and we've not been using the `Promise.resolve(undefined)` format for a long time, hence this patch fixes the few remaining cases.
2021-10-15 22:42:13 +02:00
Tim van der Meij
e504e81cda
Merge pull request #14112 from Snuffleupagus/ScrollMode-PAGE
Add a new Page scrolling mode (issue 2638, 8952, 10907)
2021-10-15 21:40:51 +02:00
Jonas Jenwald
08e2427f9c Ensure that pre-rendering works correctly with spreadModes at higher zoom levels
Having recently worked with this code, in PR 14096 (and indirectly in PR 14112), I happened to notice a pre-existing issue with spreadModes at higher zoom levels.
The `PDFRenderingQueue` code was written back when the viewer only supported "normal" vertical scrolling, and some edge-cases related to spreadModes are thus not perfectly supported. Depending on the zoom level, it's possible that there are "holes" in the currently visible page layout, and those pages will not be pre-rendered as you'd expect.

*Steps to reproduce:*

 0. Open the viewer, e.g. https://mozilla.github.io/pdf.js/web/viewer.html
 1. Enable vertical scrolling.
 2. Enable the ODD spreadMode.
 3. Scroll down, such that both pages 1 and 3 are visible.
 4. Zoom-in until *only* page 1 and 3 are visible.
 5. Open the devtools and, using the DOM Inspector, notice how page 2 is *not* being pre-rendered despite all surrounding pages being rendered.
2021-10-14 11:20:49 +02:00
Jonas Jenwald
e1a2e916e8 Move PDFSinglePageViewer into the web/pdf_viewer.js file
With the previous commit, both of the `PDFViewer` and `PDFSinglePageViewer` clases are now small/simple enough that it no longer seems necessary to keep them in separate files.
2021-10-12 13:45:19 +02:00
Jonas Jenwald
511458fbbc Add a new Page scrolling mode (issue 2638, 8952, 10907)
This implements a new Page scrolling mode, essentially bringing (and extending) the functionality from `PDFSinglePageViewer` into the regular `PDFViewer`-class. Compared to `PDFSinglePageViewer`, which as its name suggests will only display one page at a time, in the `PDFViewer`-implementation this new Page scrolling mode also support spreadModes properly (somewhat similar to e.g. Adobe Reader).

Given the size and scope of these changes, I've tried to focus on implementing the basic functionality. Hence there's room for further clean-up and/or improvements, including e.g. simplifying the CSS/JS related to PresentationMode and implementing easier page-switching with the mouse-wheel/arrow-keys.
2021-10-12 13:45:15 +02:00
Jonas Jenwald
8010181078 [Regression] Fix comb fields scrolling when the last character is entered (PR 14049 follow-up)
Note that PR 14049 removed this, since https://github.com/mozilla/pdf.js/pull/14049#discussion_r716245518 claimed that it's not necessary anymore. Unfortunately that, in my testing on Windows, actually re-introduced exactly the issue described in the comment; more specifically once the *last* character has been entered in the comb-field it's now again incorrectly scrolled (with the first character being invisible) until focus is lost.

This can be tested with e.g. `f1040.pdf`, see page 2, from the test-suite.
2021-10-05 09:36:08 +02:00
Tim van der Meij
dedff3c982
Merge pull request #14096 from Snuffleupagus/spreadMode-preRender
Pre-render *one* additional page when spreadModes are enabled
2021-10-02 12:54:19 +02:00
Jonas Jenwald
8cb6efec2d [api-minor] Add a wrapper around the addLinkAttributes-function, in the API, to the PDFLinkService implementations
This patch helps reduce some duplication, given that we now have a few essentially identical `addLinkAttributes` call-sites in the code-base.
To prevent runtime errors in the Annotation/XFA-layer code, we'll warn if a custom/incomplete `PDFLinkService` is being used (limited to GENERIC builds).
2021-10-02 12:28:00 +02:00
Jonas Jenwald
e4794a678a Pre-render *one* additional page when spreadModes are enabled
Please note that we (obviously) don't want to unconditionally pre-render more than one page all the time, since that could very easily lead to overall worse performance in some documents.[1]
However, when spreadModes are enabled it does make sense to attempt to pre-render both of the pages of the next/previous spread.

---
[1] Since it may cause pre-rendering to unnecessarily compete for parsing resources, on the worker-thread, with "regular" rendering.
2021-10-02 11:57:34 +02:00
Jonas Jenwald
fb6c807ba2 Reduce unnecessary duplication in PDFRenderingQueue.getHighestPriority 2021-10-02 11:57:32 +02:00
Jonas Jenwald
bb9c905c5d Ensure that various URL-related options are applied in the xfaLayer too
Note how both the annotationLayer and the document outline will apply various URL-related options when creating the link-elements.
For consistency the `xfaLayer`-rendering should obviously use the same options, to ensure that the existing options are indeed applied to all URLs regardless of where they originate.
2021-10-02 09:32:23 +02:00
Tim van der Meij
9a74f3e6e0
Merge pull request #14049 from calixteman/bg_from_mk
Annotation - Use border and background colors from MK dictionary
2021-09-29 21:13:20 +02:00
Calixte Denizet
0776cd9b90 Annotation - Use border and background colors from MK dictionary
- it aims to fix #13003;
  - set the bg and fg colors as they're in the pdf;
  - put a transparent overlay to help to see the fields.
2021-09-26 20:49:26 +02:00
Calixte Denizet
558e58f354 XFA - Add <a> element in button when an url is detected (bug 1716758)
- it aims to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1716758;
  - some buttons have a JS action with the pattern `app.launchURL(...)` (or similar) so extract when it's possible the url and generate a <a> element with the href equals to the found url;
  - pdf.js already had some code to handle that so this patch slightly refactor that.
2021-09-25 21:59:39 +02:00
Brendan Dahl
c3ca78fdf8
Merge pull request #14042 from serdnab/doc-info-color
Fix dialogs with forced colors (bug 1722984)
2021-09-23 18:03:04 -07:00
Brendan Dahl
d370a281c4
Merge pull request #14067 from calixteman/1732344
Don't save anything in XFA entry if no XFA! (bug 1732344)
2021-09-23 15:07:00 -07:00
Jonas Jenwald
02aa107b21
Merge pull request #14068 from kjenova/master
Fix typo "_annotatationMode" => "_annotationMode"
2021-09-23 21:22:51 +02:00
Calixte Denizet
4b0538d07a Don't save anything in XFA entry if no XFA! (bug 1732344)
- it aims to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1732344
  - rename some variables to have a more clear code;
  - and last but no least, add a unit test to test saving.
2021-09-23 19:51:23 +02:00
kjenova
d1e3900a3d
Fix typo "_annotatationMode" => "_annotationMode" 2021-09-23 18:42:33 +02:00
Jonas Jenwald
fd1f0f647f Print a special warning message, in the viewer, for XFA Foreground documents
Currently XFAF documents use the same warning message as in the XFA *disabled* case, which is neither helpful nor correct.
2021-09-23 15:02:24 +02:00
Jonas Jenwald
6cba5509f2 Re-factor document.getElementsByName lookups in the AnnotationLayer (issue 14003)
This replaces direct `document.getElementsByName` lookups with a helper method which:
 - Lets the AnnotationLayer use the data returned by the `PDFDocumentProxy.getFieldObjects` API-method, such that we can directly lookup only the necessary DOM elements.
 - Fallback to using `document.getElementsByName` as before, such that e.g. the standalone viewer components still work.

Finally, to fix the problems reported in issue 14003, regardless of the code-path we now also enforce that the DOM elements found were actually created by the AnnotationLayer code.
With these changes we'll thus be able to update form elements on all visible pages just as before, but we'll additionally update the AnnotationStorage for not-yet-rendered elements thus fixing a pre-existing bug.
2021-09-23 13:05:18 +02:00
Tim van der Meij
8dc22f40c7
Merge pull request #14063 from Snuffleupagus/disablePreferences-warning
[GENERIC viewer] Warn about AppOptions being overridden by Preferences during loading
2021-09-22 22:33:40 +02:00
Tim van der Meij
1bef4e596c
Merge pull request #14058 from Snuffleupagus/EventBus-data
[api-minor] Change `EventBus.dispatch` to only support *one* data-argument
2021-09-22 22:26:32 +02:00
Jonas Jenwald
96b38f6cbd [GENERIC viewer] Warn about AppOptions being overridden by Preferences during loading
Currently any AppOptions set using e.g. the "webviewerloaded" event listener can/will by default be overridden when the Preferences are read.
To avoid that happening the "disablePreferences"-option can be used, however unless it's been explicitly set all non-default AppOptions will be silently ignored. This patch thus attempts to improve the current situation somewhat, for third-party implementations, by logging a warning in the console when this happens.
2021-09-22 15:43:26 +02:00
Jonas Jenwald
af748050c0 [api-minor] Change EventBus.dispatch to only support *one* data-argument
This is consistent with how the `EventBus` has *always* been used internally in the viewer, and allows a slight simplification of the relevant code.
2021-09-22 12:21:33 +02:00
Jonas Jenwald
3e550f392a Add PDF_TO_CSS_UNITS to the PixelsPerInch-structure
Rather than re-computing this value in a number of different places throughout the code-base[1], we can expose this in the API via the existing `PixelsPerInch`-structure instead.
There's also been feature requests asking for the old `CSS_UNITS` viewer constant to be made accessible, such that it could be used in third-party implementations.

I suppose that it could be argued that it's somewhat confusing to place a unitless property in `PixelsPerInch`, however given that the `PDF_TO_CSS_UNITS`-property is defined strictly in terms of the existing properties this is hopefully deemed reasonable.

---
[1] These include:
 - The viewer, with the `CSS_UNITS` name.
 - The reference-tests.
 - The display-layer, when rendering images; see PR 13991.
2021-09-20 13:20:09 +02:00
Jonas Jenwald
d9f9fa4f1c Move the zoomIn/zoomOut functionality into BaseViewer (PR 14038 follow-up)
Given the simplicity of this functionality, we can move it from the default viewer and into the `BaseViewer` class instead. This way, it's possible to support more scripting functionality in the standalone viewer components; please see PR 14038.

Please note that I purposely went with `increaseScale`/`decreaseScale`-method names, rather than using "zoom", to better match the existing `currentScale`/`currentScaleValue` getters/setters that's being used in the `BaseViewer` class.
2021-09-19 11:54:57 +02:00
Tim van der Meij
2375318a70
Merge pull request #14005 from Snuffleupagus/issue-13997
[GENERIC viewer] Always show the Download-buttons, to allow saving of forms (issue 13997)
2021-09-18 16:31:15 +02:00
Tim van der Meij
213f3d4cbf
Merge pull request #14043 from Snuffleupagus/AutomationEventBus
Re-factor the `EventBus` and `isInAutomation` handling (PR 11655 follow-up)
2021-09-18 16:02:55 +02:00
Calixte Denizet
bfd570038d JS - Implement few possibilities with app.execMenuItem (bug 1724399)
- it aims to fix: https://bugzilla.mozilla.org/show_bug.cgi?id=1724399.
2021-09-18 13:52:32 +02:00
Jonas Jenwald
0e92f995c9 Re-factor the EventBus and isInAutomation handling (PR 11655 follow-up)
Rather than forcing the "regular" `EventBus` to check and handle `isInAutomation` for every `dispatch` call, we can take advantage of subclassing instead.
Hence this PR introduces a new `AutomationEventBus` class, which extends `EventBus`, and is used by the default viewer when `isInAutomation === true`.
2021-09-18 09:59:53 +02:00
unknown
a3cc2e63eb removed unnecessary variable setting 2021-09-17 18:43:31 -03:00
Jonas Jenwald
9745b75858 [GENERIC viewer] Always show the Download-buttons, to allow saving of forms (issue 13997)
Originally the library/viewer didn't support forms, and the hiding of the Download-buttons (when new documents are opened) didn't really matter all that much. Hence the simplest solution, at the time, was to hide the Download-buttons since we use the URL as a fallback when downloading data in the GENERIC `DownloadManager`.
Nowadays we obviously want to support saving of forms in the GENERIC viewer, regardless of how the document was opened, which could thus *potentially* lead to the fallback download-URL being wrong.

In order to be able to show the Download-buttons unconditionally, this patch slightly re-factors the viewer to track the download-URL *separately* to prevent any issues there.

*Please note:* As mentioned in the issue, the ViewBookmark-buttons are specific to the initial URL when the viewer is first opened. Hence they (still) don't make sense when a new document has been opened, since it's then impossible to obtain a usable link to the *currently* active document.
2021-09-15 23:51:56 +02:00
Tim van der Meij
95435ed66f
Merge pull request #13984 from Snuffleupagus/viewer-enableXfa
Enable XFA by default in the viewer, and `components/` examples (issue 13968)
2021-09-15 22:44:59 +02:00
Jonas Jenwald
4a7976f097 Use CSS variables for setting the width of the zoom dropdown (PR 11570 follow-up)
By using CSS variables to set the width of the zoom dropdown, we can simplify both the relevant CSS and JS code. This will not only improve overall maintainability of this code, but should also make it (slightly) easier for third-party users that want to customize the width.

Note in particular that by having the code in `Toolbar._adjustScaleWidth` lookup the values of the CSS variables, we no longer need to worry about keeping hard-coded values up-to-date with the CSS rules.
2021-09-15 15:51:30 +02:00
Jonas Jenwald
7498b97aaa Enable XFA by default in the viewer, and components/ examples (issue 13968)
Given that https://bugzilla.mozilla.org/show_bug.cgi?id=1727396 has now landed, it should now be OK to make this change.
2021-09-14 16:54:36 +02:00
Rob Wu
628e672765 [CRX] enableScripting=false by default in Chrome extension
The scripting engine is bundled for users who'd like to use the feature,
but it is disabled by default.
2021-09-12 01:13:27 +02:00
Tim van der Meij
9b42ae9612
Merge pull request #13993 from Snuffleupagus/app-pdfHistory-init
Don't create `PDFViewerApplication.pdfHistory` when the browsing history is disabled
2021-09-11 13:21:42 +02:00
Jonas Jenwald
0e54f568fb Re-factor the CSS_PIXELS_PER_INCH/PDF_PIXELS_PER_INCH exports (PR 13991 follow-up)
For improved maintainability, since these constants are being exposed in the official API, this patch moves them into an Object instead.
2021-09-11 11:15:25 +02:00
Brendan Dahl
f38fb42b42 Enable/disable image smoothing based on image interpolate value. (bug 1722191)
While some of the output looks worse to my eye, this behavior more
closely matches what I see when I open the PDFs in Adobe acrobat.

Fixes: #4706, #9713, #8245, #1344
2021-09-10 14:23:35 -07:00
Jonas Jenwald
aa289b17b6 Don't create PDFViewerApplication.pdfHistory when the browsing history is disabled
Similar to other viewer components, e.g. the `PDFFindBar` and `PDFPresentationMode`, there's no need to create a `PDFHistory`-instance when it's not going to be used.
2021-09-09 14:21:15 +02:00
Jonas Jenwald
8466204384 [GENERIC viewer] Add fallback logic for the old PDFPageView.update method signature
This is done separately from the previous commit, to make it easier to revert these changes in the future.
2021-09-04 11:39:34 +02:00
Jonas Jenwald
7c81a8dd40 [api-minor] Change {PDFPageView, PDFThumbnailView}.update to take a parameter object
The old `update`-signature started to annoy me back when I added optional content support to the viewer, since we're (often) forced to pass in a bunch of arguments that we don't care about whenever these methods are called.

This is tagged `api-minor` since `PDFPageView` is being used in the `pageviewer` component example, and it's thus possible that these changes could affect some users; the next commit adds fallback handling for the old format.
2021-09-04 11:39:25 +02:00
Jonas Jenwald
c6d400ed06 Export the XFA/StructTree-layers in the viewer components
While e.g. the `simpleviewer` and `singlepageviewer` examples work, since they're based on the `BaseViewer`-class, the standalone `pageviewer` example currently doesn't support either XFA- or StructTree-layers. This seems like an obvious oversight, which can be easily addressed simply by exporting the necessary functionality through `pdf_viewer.component.js`, similar to the existing Text/Annotation-layers.

While working on, and testing, these changes I happened to notice a number of smaller things that's also fixed in this patch:

 - Ensure that `XfaLayerBuilder.render` always have a *consistent* return type, to prevent possible run-time failures in `PDFPageView`; PR 13908 follow-up.

 - Change the order of the options in the `XfaLayerBuilder`-constructor to agree with the parameter order in the `DefaultXfaLayerFactory.createXfaLayerBuilder`-method.

 - Add a missing `textHighlighterFactory`-option, in the JSDocs for the `PDFPageView`-class.

 - A couple of small tweaks in the `TextLayerBuilder.render`-method: Re-use an existing Array rather than creating a new one, and replace an `if` with optional chaining instead.

*Please note:* For now XFA-support is currently disabled by default, similar to the regular viewer.
2021-08-28 18:43:08 +02:00
Tim van der Meij
b0929dceba
Merge pull request #13940 from Snuffleupagus/cleanup-supportsFullscreen
Simplify the `PDFViewerApplication.supportsFullscreen` getter
2021-08-27 22:31:31 +02:00
Jonas Jenwald
bc2bb18af7 Simplify the PDFViewerApplication.supportsFullscreen getter
A lot of the code in this getter has existed ever since the initial PresentationMode-implementation was first added all the way back in PR 1938 (which is nine years ago now).
At this point in time however, there's now a simpler way detect if a browser supports the FullScreen API and we should thus be able to simplify this getter; please refer to https://developer.mozilla.org/en-US/docs/Web/API/Document/fullscreenEnabled#browser_compatibility
2021-08-27 17:51:55 +02:00
Jonas Jenwald
8ff0f8e4df Use optional chaining even more in the web/app.js file 2021-08-27 17:29:00 +02:00
Michael Wu
c08b4ea30d Fix Viewer API definitions and include in CI
The Viewer API definitions do not compile because of missing imports and
anonymous objects are typed as `Object`. These issues were not caught
during CI because the test project was not compiling anything from the
Viewer API.

As an example of the first problem:

```
/**
 * @implements MyInterface
 */
export class MyClass {
    ...
}
```

will generate a broken definition that doesn’t import MyInterface:

```
/**
 * @implements MyInterface
 */
export class MyClass implements MyInterface {
    ...
}
```

This can be fixed by adding a typedef jsdoc to specify the import:

```
/** @typedef {import("./otherFile").MyInterface} MyInterface */
```

See https://github.com/jsdoc/jsdoc/issues/1537 and
https://github.com/microsoft/TypeScript/issues/22160 for more details.

As an example of the second problem:

```
/**
 * Gets the size of the specified page, converted from PDF units to inches.
 * @param {Object} An Object containing the properties: {Array} `view`,
 *   {number} `userUnit`, and {number} `rotate`.
 */
function getPageSizeInches({ view, userUnit, rotate }) {
    ...
}
```

generates the broken definition:

```
function getPageSizeInches({ view, userUnit, rotate }: Object) {
    ...
}
```

The jsdoc should specify the type of each nested property:

```
/**
 * Gets the size of the specified page, converted from PDF units to inches.
 * @param {Object} options An object containing the properties: {Array} `view`,
 *   {number} `userUnit`, and {number} `rotate`.
 * @param {number[]} options.view
 * @param {number} options.userUnit
 * @param {number} options.rotate
 */
```
2021-08-25 18:45:46 -04:00
Tim van der Meij
ada283cc35
Merge pull request #13935 from Snuffleupagus/TextHighlighter-tweaks
A couple of small `TextHighlighter`/`TextLayerBuilder` tweaks (PR 13908 follow-up)
2021-08-25 23:06:51 +02:00
Jonas Jenwald
fa4e82c453 A couple of small TextHighlighter/TextLayerBuilder tweaks (PR 13908 follow-up)
- Use `Node.TEXT_NODE` rather than a magical constant, in `TextHighlighter._convertMatches`, to improve readability. According to MDN, this has been supported since "forever": https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeType#browser_compatibility

 - Remove the `pageIdx`-property, on `TextLayerBuilder`-instances, since the re-factoring in PR 13908 meant that it's now unused.

 - Remove the `matches`-property, on `TextLayerBuilder`-instances, since the re-factoring in PR 13908 meant that it's now unused.
2021-08-25 14:14:44 +02:00
Jonas Jenwald
ae90d9162b Remove the IPDFHistory interface
Generalizing, and documenting, the `PDFHistory`-implementation as part of the web-interfaces doesn't seem entirely necessary and in hindsight I'm not entirely sure why we need it since:

 - The `PDFHistory` implementation is/was written specifically for the default viewer use-case, which is why e.g. the `simpleviewer` component example isn't using it. (While it *could* be used there, it'd need to be manually created/initialized correctly.)

 - There's only *one* `PDFHistory`-implementation present (and no other viewer-component will fail without it being available), as opposed to the other web-interfaces documented in this file.

 - The `PDFHistory` implementation is not even usable with e.g. the `pageviewer` component example, since it (obviously) requires a complete viewer to work. (This is in contrast to e.g. `IPDFTextLayerFactory` and `IPDFAnnotationLayerFactory`.)
2021-08-25 12:44:55 +02:00
Jonas Jenwald
41efa3c071 [api-minor] Introduce a new annotationMode-option, in PDFPageProxy.{render, getOperatorList}
*This is a follow-up to PRs 13867 and 13899.*

This patch is tagged `api-minor` for the following reasons:
 - It replaces the `renderInteractiveForms`/`includeAnnotationStorage`-options, in the `PDFPageProxy.render`-method, with the single `annotationMode`-option that controls which annotations are being rendered and how. Note that the old options were mutually exclusive, and setting both to `true` would result in undefined behaviour.

 - For improved consistency in the API, the `annotationMode`-option will also work together with the `PDFPageProxy.getOperatorList`-method.

 - It's now also possible to disable *all* annotation rendering in both the API and the Viewer, since the other changes meant that this could now be supported with a single added line on the worker-thread[1]; fixes 7282.

---
[1] Please note that in order to simplify the overall implementation, we'll purposely only support disabling of *all* annotations and that the option is being shared between the API and the Viewer. For any more "specialized" use-cases, where e.g. only some annotation-types are being rendered and/or the API and Viewer render different sets of annotations, that'll have to be handled in third-party implementations/forks of the PDF.js code-base.
2021-08-24 01:13:02 +02:00
Brendan Dahl
bf5a45ce6d
Merge pull request #13908 from brendandahl/xfa-find
[api-minor] XFA - Support text search in XFA documents.
2021-08-23 08:53:02 -07:00
Brendan Dahl
bb47128864 XFA - Support text search in XFA documents.
Moves the logic out of TextLayerBuilder to handle
highlighting matches into a new separate class `TextHighlighter`
that can be used with regular PDFs and XFA PDFs.

To mimic the current find functionality in XFA, two arrays
from the XFA rendering are created to get the text content
and map those to DOM nodes.

Fixes #13878
2021-08-23 08:44:20 -07:00
Tim van der Meij
50dffdaf55
Merge pull request #13905 from Snuffleupagus/refactor-loadAndEnablePDFBug
Re-factor `loadAndEnablePDFBug` and `PDFBug.init`
2021-08-21 14:39:57 +02:00
Jonas Jenwald
88d39e51c3 When running tests, enable XFA by default in the viewer (PR 13745 follow-up) 2021-08-19 20:13:19 +02:00
Jonas Jenwald
bc8787b049 Re-factor loadAndEnablePDFBug and PDFBug.init
The `loadAndEnablePDFBug` helper function, in `web/app.js`, can be simplified a little bit by making it `async`. Furthermore, given how `PDFBug` is being used, we can also (slightly) re-factor `PDFBug.init` such that the `PDFBug.enable`-call is done internally rather than having to handle that manually at the call-site.

(Finally, utilize `await` more in the `loadFakeWorker` helper function.)
2021-08-19 12:06:23 +02:00
Jonas Jenwald
474659be8b Fix the inconsistent return types in PDFViewerApplication._parseHashParameters
While not really relevant to the previous patches, this fixes a small inconsistency in the code.
2021-08-10 11:27:49 +02:00
Jonas Jenwald
5ac139dea1 Remove the BaseViewer._name property, used only when logging errors
The original idea behind including the class name, when logging errors, was to improve things in the *hypothetical case* where `PDFViewer`- and `PDFSinglePageViewer`-instances would be used side-by-side.
Given that all of the relevant methods are synchronous this seem unlikely to really be necessary, and furthermore it's probably best to avoid using `this.constructor.name` since that's not guaranteed to do what you intend (we've seen repeated issues with minifiers mangling function/class names).
2021-08-10 11:27:49 +02:00
Jonas Jenwald
1cf9405281 [api-minor] Remove the closure from the PDFWorker class, in the src/display/api.js file
This patch removes the only remaining closure in the `src/display/api.js` file, utilizing a similar approach as used in lots of other parts of the code-base, which results in a small decrease in the size of the *build* `pdf.js` file.

Given that `PDFWorker` is exposed through the *public* API, this complicates things somewhat since there's a couple of worker-related properties that really should stay *private*. Initially, while working on PR 13813, I believed that we'd need support for private (static) class fields in order to get rid of this closure, however I've managed to come up with what's hopefully deemed an acceptable work-around here.
Furthermore, some helper functions were simply moved into the `PDFWorker` class as static methods, thus simplifying the overall implementation (e.g. we don't need to manually cache the Promise in the `PDFWorker._setupFakeWorkerGlobal`-method).

Finally, as part of this re-factoring a number of missing JSDoc-comments were added which *together* with the removal of the closure significantly improves the `gulp jsdoc` output for the `PDFWorker` class.

*Please note:* This patch is tagged with `api-minor` since it deprecates `PDFWorker.getWorkerSrc()` in favor of the shorter `PDFWorker.workerSrc`, with the fallback limited to `GENERIC` builds.
2021-08-07 10:43:39 +02:00
Tim van der Meij
849bab973c
Merge pull request #13874 from Snuffleupagus/components-annotation-zoom-factor
Update the Annotation `--zoom-factor` CSS variable when `PDFPageView` is used standalone (PR 13868 follow-up)
2021-08-05 22:28:51 +02:00
Calixte Denizet
fef939d347 Annotation & XFA: Add focus outlines on different fields (bug 1723615, bug 1718528)
- set a default tabindex to be sure they'll be taken into account in the TAB cycle (https://bugzilla.mozilla.org/show_bug.cgi?id=1723615).
  - show default outline when fields are focused (it was an a11y bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1718528).
2021-08-05 13:33:46 +02:00
Jonas Jenwald
561faa7c94 Update the Annotation --zoom-factor CSS variable when PDFPageView is used standalone (PR 13868 follow-up)
Without this patch, when using `PDFPageView` directly[1] this CSS variable won't be updated and consequently things won't work as intended.
This is purposely implemented such that when a `PDFPageView`-instance is part of a viewer, we don't repeatedly set the CSS variable for every single page.

---
[1] See e.g. the "pageviewer" example in the `examples/components/` folder.
2021-08-05 11:43:43 +02:00