Commit Graph

2940 Commits

Author SHA1 Message Date
calixteman
63471bcbbe
XFA - Convert some template properties into CSS ones (#13082)
- implement few positioning properties: position, width, height, anchor;
  - implement font element;
  - implement fill element (used by font) and its children (linear, radial, ...);
  - font property is inherited from ancestor container (see https://www.pdfa.org/wp-content/uploads/2020/07/XFA-3_3.pdf#page=43) so let CSS handles that stuff;
  - in order to reduce the number of properties to set, only set non default properties and put the default in CSS;
  - set a background to some containers to be able to see them (will be removed in a future commit).
2021-03-25 13:02:39 +01:00
Jonas Jenwald
a10f87c7ea [PDFHistory] Correctly simulate an internal destination in the pushPage-method (PR 12493 follow-up)
The intention, in PR 12493, was that the page we're adding to the browser history should behave as if it were a "regular" internal destination (to properly convey user intent).
Unfortunately, since I didn't consider all the edge-cases correctly, it ended up behaving like a URL-hash instead which obviously wasn't intended. Note that currently this isn't a problem, however it can become an issue (in some cases) with upcoming re-factoring around `PDFHistory` and OpenAction support[1].

---
[1] I've started working on fixing the following TODO, which will require a couple of smaller tweaks here and there: 9d0ce6e79f/web/app.js (L1680-L1681)
2021-03-25 12:24:28 +01:00
Jonas Jenwald
685a60055e [PDFHistory] Reduce unnecessary duplication, by introducing a helper-method for validating pageNumbers 2021-03-24 22:01:53 +01:00
Tim van der Meij
9d0ce6e79f
Merge pull request #13128 from Snuffleupagus/BasePreferences-loops
Re-factor how the `BasePreferences.prefs`-property is initialized; remove some *indirect* loops
2021-03-24 20:47:45 +01:00
Ikko Ashimine
0de15d59b8
Fix typo in pdf_history.js
occuring -> occurring
2021-03-24 23:18:40 +09:00
Jonas Jenwald
be52183211 Remove some *indirect* loops in the BasePreferences.getAll-method
In the `getAll`-method, we can have just one *explicit* loop rather than two indirect ones via the old `Object.assign`-call.

Also, changes the `get`-method to be slightly more compact (while keeping the logic intact).
2021-03-22 14:38:05 +01:00
Jonas Jenwald
4b27f58625 Re-factor how the BasePreferences.prefs-property is initialized
Looking at this now, I cannot understand why we'd need to initialize `this.prefs` with all of the values from `this.defaults`.
Not only does this *indirectly* require one extra loop, via the `Object.assign`-call, but it also means that in GENERIC-builds changes to default-preference values might not be picked-up unless the the existing user-prefs are cleared (if the user had *manually* set prefs previously).
2021-03-22 14:37:56 +01:00
Jonas Jenwald
35a088ffc1 Don't provide the enableXfa parameter to the BaseViewer constructor, and avoid the fallback bar with enableXfa = true set (PR 13069 follow-up)
Given that the `enableXfa` parameter must to be passed to the API/Worker, and thus included in the `getDocument` call, it's not necessary to include it when initializing the `PDFViewer`-instance used in the default viewer. (Also, in `AppOptions`, the parameter is clearly marked with `OptionKind.API`.)

Furthermore, we probably don't want to display the fallback bar (in Firefox) for XFA documents when `enableXfa = true` is set.
2021-03-21 10:52:01 +01:00
Tim van der Meij
c6b44d1516
Merge pull request #13117 from Snuffleupagus/defaultPreferences-builds
Re-factor the default preferences generation to support build targets (PR 10548)
2021-03-20 18:40:29 +01:00
Jonas Jenwald
71e61c3533 Tweak the pre-processor condition, for Node.js environments, in the animationStarted helper (issue 13057)
While it's still not entirely clear if this would've prevented the issue as reported, given that the particular use-case reported apparently no longer applies, this small change really cannot hurt in general *and* it won't effect "regular" viewer builds in any way.
2021-03-20 13:34:38 +01:00
Jonas Jenwald
7bcfabc43c Fix an edge-case related to compatibility-values in various AppOptions-methods
Given how the compatibility-values are being handled, it's not actually possible to override a *truthy* default-value with a *falsy* compatibility-value.
This is a simple oversight on my part, and with modern ECMAScript features this is very easy to support.
2021-03-20 13:12:09 +01:00
Jonas Jenwald
18bc59eb34 [Chromium extension] Remove the special handling of the "disableTelemetry" preference
With the changes made in the previous patch, we can now list "disableTelemetry" in the `AppOptions` only for the `CHROME`-builds and thus remove the special-casing in the `checkChromePreferencesFile` helper function.
2021-03-20 13:12:09 +01:00
Jonas Jenwald
56e1d7746a Re-factor the default preferences generation to support build targets (PR 10548)
Originally the default preferences where simply placed in a JSON-file, checked into the repository, which over time became impractical, annoying, and error-prone to maintain; please see PR 10548.
While that improved the overall situation a fair bit, it however inherited one quite unfortunate property of the old JSON-based solution[1]: It's still not possible for *different* build targets to specify their *own* default preference values.

With some preferences, such as e.g. `enableScripting`, it's not inconceivable that you'd want to (at least) support build-specific default preference values. Currently that's not really possible, which is why this PR re-factors the default preferences generation to support this.

---
[1] This fact isn't really clear from the `AppOptions` implementation, unless you're familiar with the `gulpfile.js` code, which could lead to some confusion for those new to this part of the code-base.
2021-03-20 11:50:48 +01:00
Tim van der Meij
d775616fd4
Merge pull request #13118 from brendandahl/page-aria
Add landmark region and aria-label for each page.
2021-03-19 23:17:55 +01:00
Tim van der Meij
8269ddbd16
Merge pull request #13105 from Snuffleupagus/BasePdfManager-parseDocBaseUrl
Improve memory usage around the `BasePdfManager.docBaseUrl` parameter (PR 7689 follow-up)
2021-03-19 23:03:20 +01:00
Tim van der Meij
e7e0ecf9c8
Merge pull request #13113 from Snuffleupagus/scripting-PresentationMode-events
Ignore some *scripting* events which don't make sense in PresentationMode
2021-03-19 22:52:15 +01:00
Tim van der Meij
92d3a93897
Merge pull request #13116 from Snuffleupagus/enableScripting-true
Enable scripting by default in the viewer (PR 13053 follow-up)
2021-03-19 22:48:57 +01:00
Brendan Dahl
9fb0f3b0da Add landmark region and aria-label for each page.
Allows screen readers to jump landmarks and announce
the page. Since landmarks must have content, I also added
aria labels for the loading images.
2021-03-19 14:13:51 -07:00
Jonas Jenwald
1fa5ce7f48 Ignore some *scripting* events which don't make sense in PresentationMode
A number of the currently supported *scripting* events only make sense in the "normal" viewer mode, and not when PresentationMode is active. For example:
 - Changing the zoom-level will outright break rendering in PresentationMode, since it relies on "page-fit" being used.
 - Focusing a particular (AcroForm) element won't work, and could break keyboard navigation, since forms should not be editable in PresentationMode (see issue 12232).
2021-03-19 13:54:21 +01:00
Jonas Jenwald
30c06849d8 Rotate landscape pages, during printing, by default in the viewer (enablePrintAutoRotate = true)
While this will perhaps not be perfect for *every* PDF document with mixed page orientation, based on the large number of bugs/issues seen over the years I'm however pretty convinced that it'll be an overall improvement in a majority of cases.

In order to improve things further, we'd probably need Firefox to support e.g. `@page` such that the viewer can provide better information to the print engine.
2021-03-19 12:39:37 +01:00
Jonas Jenwald
1de466896d Remove one loop from BaseViewer.getPagesOverview
Currently, with `enablePrintAutoRotate = true` set, we're forced to loop through all the pages *twice* when checking for any landscape pages.
This seems completely unnecessary now, and using only *one* loop should be marginally more efficient in general.
2021-03-19 12:38:46 +01:00
Jonas Jenwald
3ce94a9f6d Change how landscape pages are rotated, for printing, with enablePrintAutoRotate = true set
Currently landscape pages are rotated *clockwise*, which for most documents feel wrong since holding the printed pages at their *left* edge causes the landscape pages to be viewed "upside down".
In general, since most documents are LTR ones, it feels more appropriate to instead rotate landscape pages *counterclockwise* for printing.
2021-03-19 12:37:57 +01:00
calixteman
24e598a895
XFA - Add a layer to display XFA forms (#13069)
- add an option to enable XFA rendering if any;
  - for now, let the canvas layer: it could be useful to implement XFAF forms (embedded pdf in xml stream for the background and xfa form for the foreground);
  - ui elements in template DOM are pretty close to their html counterpart so we generate a fake html DOM from template one:
    - it makes easier to translate template properties to html ones;
    - it makes faster the creation of the html element in the main thread.
2021-03-19 10:11:40 +01:00
Jonas Jenwald
2d727e6e68 Enable scripting by default in the viewer (PR 13053 follow-up)
Given that https://bugzilla.mozilla.org/show_bug.cgi?id=1699219 has enabled scripting for all Firefox-channels, it seems reasonable to simply set `enableScripting = true` unconditionally in the viewer preferences/options.

For now, this patch leaves the standalone viewer-components alone (such as e.g. `BaseViewer`), and if those are used scripting will thus have to be manually enabled (see e.g. the "simpleviewer"/"singlepageviewer" examples).
2021-03-17 21:14:08 +01:00
Jonas Jenwald
bd9dee1544 Move the getPdfFilenameFromUrl helper function from web/ui_utils.js and into src/display/display_utils.js
It seems reasonable to place this alongside the *similar* `getFilenameFromUrl` helper function. This way, with the changes in the next patch, we also avoid having to expose the `isDataScheme` function in the API itself and we instead expose `getPdfFilenameFromUrl` in the API (which feels overall more appropriate).
2021-03-17 15:48:24 +01:00
Jonas Jenwald
d92b77e87f
Ensure that printing, triggered from scripting, won't accidentally throw in PDFScriptingManager._updateFromSandbox (#13104)
The issue that this patch fixes is extremely unlikely, but still theoretically possible, and I really should've caught this earlier.
Note how `BaseViewer.pagesPromise` will only be defined when a document is active, see below, and that if a printing event (triggered from scripting) arrives while the document is been closed there's a small chance that the promise isn't defined.

eb92ed12f2/web/base_viewer.js (L426-L428)
2021-03-16 14:22:39 +01:00
Emilio Cobos Álvarez
1d70bfe6e6 print: RFC: Center when printing a PDF with smaller size than the output page.
This builds on top of #13100, but this changes printing behavior intentionally
so I thought it was worth discussing separately, to improve the rendering on
test-cases like the one in https://bugzil.la/1697778.

This matches what e.g.  Evince does when you print the PDF in there on an A4
printer.

We use margins to center horizontally, and flex to center vertically. The
reasoning for this is that it should have better browser support (though maybe
pdf.js no longer supports browsers without flex support?) and it's just as
simple.
2021-03-15 09:51:53 +01:00
Tim van der Meij
eb92ed12f2
Merge pull request #13100 from emilio/container-overflow
print: Ensure print containers have the right size and don't create overflow.
2021-03-14 15:53:50 +01:00
Emilio Cobos Álvarez
b932eaf6a7 print: Remove invalid @supports condition.
@supports() is not supposed to report support for page descriptors, this is
depending on a Chromium bug, which doesn't treat as invalid:

```
<div style="size: 1pt 1pt">
```

Even though it should. That is
https://bugs.chromium.org/p/chromium/issues/detail?id=1079214

There's no need to use @supports for this. If the descriptor is not accepted it
will just be ignored.

That way, when Firefox implements @page { size }, which is in progress, it will
get the right behavior.
2021-03-14 15:15:04 +01:00
Emilio Cobos Álvarez
baed09f1ff
print: Ensure print containers have the right size and don't create overflow.
First, there's just no need to do something like this, this is simpler and
closer to what the screen renderer does.

Second, this causes overflow, which Firefox tries to compensate for when
fitting to page width, and fails at it. That is tracked in:

https://bugzilla.mozilla.org/show_bug.cgi?id=1698136

But this bug works around it by not causing overflow.

For modern browsers, we could avoid the duplication setting the style attribute
by using something like width: min/max-content, but this is not a big deal I
think, let me know if you'd prefer that.

Also I had to add a max-height for Chromium not to create extra pages. This
is harmless in Firefox and workarounds the Chromium bug, so so be it.
2021-03-14 14:49:46 +01:00
Jonas Jenwald
5b5061afa8 Enable the ESLint no-var rule globally
A significant portion of the code-base has now been converted to use `let`/`const`, rather than `var`, hence it should be possible to simply enable the ESLint `no-var` rule globally.
This way we can ensure that new code won't accidentally use `var`, and it also removes the need to manually enable the rule in various folders.

Obviously it makes sense to continue the efforts to replace `var`, but that should probably happen on a file and/or folder basis.

Please note that this patch excludes the following code:
 - The `extensions/` folder, since that seemed easiest for now (and I don't know exactly what the support situation is for the Chromium-extension).

 - The entire `external/` folder is ignored, since most of it's currently excluded from linting.
   For the code that isn't imported from elsewhere (and should be ignored), we should probably (at some point) bring the code up to the same linting/formatting standard as the rest of the code-base.

 - Various files in the `test/` folder are ignored, as necessary, since the way that a lot of this code is loaded will require some care (or perhaps larger re-factoring) when removing `var` usage.
2021-03-13 16:12:53 +01:00
Jonas Jenwald
412f01aeaf Dispatch a "Doc/WillClose" event, when scripting is enabled, when closing the document
This event is mentioned in the specification, see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/AcrobatDC_js_api_reference.pdf#G5.1963176, and it's also listed as a valid type in fb87704b38/src/shared/util.js (L164-L170)

Since we're already dispatching a "PageClose" event in this case, it seems reasonable to *also* dispatch a "Doc/WillClose" event as well.
2021-03-13 13:21:05 +01:00
Jonas Jenwald
52a598915f Re-factor the PDFScriptingManager._destroyScripting method (PR 13042 follow-up)
*Please note:* Given the pre-existing issues raised in PR 13056, which seem to block immediate progress there, this patch extracts some *overall* improvements of the scripting/sandbox destruction in `PDFScriptingManager`.

As can be seen in `BaseViewer.setDocument`, it's currently necessary to *manually* delay the `PDFScriptingManager`-destruction in order for things to work correctly. This is, in hindsight, obviously an *extremely poor* design choice on my part; sorry about the churn here!

In order to improve things overall, the `PDFScriptingManager._destroyScripting`-method is re-factored to wait for the relevant events to be dispatched *before* sandbox-destruction occurs.
To avoid the scripting/sandbox-destruction hanging indefinitely, we utilize a timeout to force-destroy the sandbox after a short time (currently set to 1 second).
2021-03-10 13:08:19 +01:00
Jonas Jenwald
bc13932ac1 Use more optional chaining in the web/-folder (PR 12961 follow-up)
I overlooked these cases previously, but there's no reason why optional chaining (and nullish coalescing) cannot be used here as well.
2021-03-07 16:20:52 +01:00
Jonas Jenwald
bdde621366 Avoid unnecessary size_kb calculation, for large files, in PDFDocumentProperties._parseFileSize (PR 13050 follow-up) 2021-03-07 16:10:11 +01:00
Jonas Jenwald
87dd93b7fc Move handling of the PageOpen/PageClose events into the PDFScriptingManager (PR 13042 follow-up)
By moving this code from the `BaseViewer` and into `PDFScriptingManager`, all of the scripting initialization/handling code is now limited to just one file/class which help overall readability (in my opinion). Also, this patch is a *net reduction* in number of lines of code which can never hurt.

As part of these changes, the intermediary "pageopen"/"pageclose" events are now removed in favor of using the "regular" viewer events directly in `PDFScriptingManager`. Hence this removes some (strictly unnecessary) indirection in the current code, when handling PageOpen/PageClose events, which leads to overall fewer function calls in this part of the code.
2021-03-06 10:12:32 +01:00
Jonas Jenwald
a6d1cba38c [api-minor] Move the viewer scripting initialization/handling into a new PDFScriptingManager class
The *main* purpose of this patch is to allow scripting to be used together with the viewer components, note the updated "simpleviewer"/"singlepageviewer" examples, in addition to the full default viewer.
Given how the scripting functionality is currently implemented in the default viewer, trying to re-use this with the standalone viewer components would be *very* hard and ideally you'd want it to work out-of-the-box.

For an initial implementation, in the default viewer, of the scripting functionality it probably made sense to simply dump all of the code in the `app.js` file, however that cannot be used with the viewer components.
To address this, the functionality is moved into a new `PDFScriptingManager` class which can thus be handled in the same way as all other viewer components (and e.g. be passed to the `BaseViewer`-implementations).

Obviously the scripting functionality needs quite a lot of data, during its initialization, and for the default viewer we want to maintain the current way of doing the lookups since that helps avoid a number of redundant API-calls.
To that end, the `PDFScriptingManager` implementation accepts (optional) factories/functions such that we can maintain the current behaviour for the default viewer. For the viewer components specifically, fallback code-paths are provided to ensure that scripting will "just work"[1].

Besides moving the viewer handling of the scripting code to its own file/class, this patch also takes the opportunity to re-factor the functionality into a number of helper methods to improve overall readability[2].
Note that it's definitely possible that the `PDFScriptingManager` class could be improved even further (e.g. for general re-use), since it's still heavily tailored to the default viewer use-case, however I believe that this patch is still a good step forward overall.

---

[1] Obviously *all* the relevant document properties might not be available in the viewer components use-case (e.g. the various URLs), but most things should work just fine.

[2] The old `PDFViewerApplication._initializeJavaScript` method, where everything was simply inlined, have over time (in my opinion) become quite large and somewhat difficult to *easily* reason about.
2021-03-05 20:31:48 +01:00
Jonas Jenwald
5b9638329c Move apiPageLayoutToSpreadMode and apiPageModeToSidebarView from web/app.js and into web/ui_utils.js
These changes will be necessary for the next patch, since we don't want to accidentally pull in the entire default viewer in the standalone viewer components.
2021-03-05 20:31:48 +01:00
Jonas Jenwald
7dc1bbf05e Enable scripting by default in the development viewer
Given that scripting is now enabled in Firefox Nightly (but only there), it seems weird to not have scripting enabled by default in `gulp server` mode.
2021-03-04 23:56:51 +01:00
Jonas Jenwald
038668bf8c Collect all l10n fallback strings, used in the viewer, in one helper function (PR 12981 follow-up)
Rather than having to spell out the English fallback strings at *every* single `IL10n.get` call-site throughout the viewer, we can simplify things by collecting them in *one* central spot.
This provides a much better overview of the fallback l10n strings used, which makes future changes easier and ensures that fallback strings occuring in multiple places cannot accidentally get out of sync.
Furthermore, by making the `fallback` parameter of the `IL10n.get` method *optional*[1] many of the call-sites (and their surrounding code) become a lot less verbose.

---
[1] It's obviously still possible to pass in a fallback string, it's just not required.
2021-03-04 11:34:51 +01:00
Jonas Jenwald
7c52c01267 Change the background to ensure that the sidebar is visible/readable when the viewer is narrow (issue 13036)
This is more fallout from PR 11077.
2021-03-01 18:27:27 +01:00
Jonas Jenwald
6fd899dc44 [api-minor] Support the Content-Disposition filename in the Firefox PDF Viewer (bug 1694556, PR 9379 follow-up)
As can be seen [in the mozilla-central code](https://searchfox.org/mozilla-central/rev/a6db3bd67367aa9ddd9505690cab09b47e65a762/toolkit/components/pdfjs/content/PdfStreamConverter.jsm#1222-1225), we're already getting the Content-Disposition filename. However, that data isn't passed through to the viewer nor to the `PDFDataTransportStream`-implementation, which explains why it's currently being ignored.

*Please note:* This will also require a small mozilla-central patch, see https://bugzilla.mozilla.org/show_bug.cgi?id=1694556, to forward the necessary data to the viewer.
2021-02-26 10:50:29 +01:00
Tim van der Meij
061637d3f4
Merge pull request #13021 from Snuffleupagus/createObjectURL-rm-shadow
Remove the, strictly unnecessary, closure and variable shadowing from `createObjectURL`
2021-02-25 23:35:17 +01:00
Tim van der Meij
163a840a1e
Merge pull request #13020 from Snuffleupagus/rm-some-NullL10n-use
Remove the `NullL10n` default value from viewer components not included in the `COMPONENTS`-bundle
2021-02-25 23:27:49 +01:00
Jonas Jenwald
70d1869fe5 Remove the, strictly unnecessary, closure and variable shadowing from createObjectURL
Note that this particular helper function is, with the exception of the `GENERIC` default viewer and the (unsupported) SVG-backend, mostly unused at this point in time. Hence we should be able to clean-up this helper function slightly.

Also, fixes a small inconsistency in the `SVGGraphics` initialization in the viewer, by passing in the `disableCreateObjectURL` compatibility-option. Given that the SVG-backend isn't officially supported/recommended this shouldn't have been an issue, but given that I spotted this it can't hurt to fix it.
2021-02-25 16:34:23 +01:00
Jonas Jenwald
85251da218 Remove the NullL10n default value from viewer components not included in the COMPONENTS-bundle
For any viewer component not listed in `web/pdf_viewer.component.js`, it shouldn't be necessary to provide a default value for the `l10n`-parameters.
Note also that these *specific* components are heavily tailored towards the default viewer use-case, rather than for general usage.
2021-02-25 16:08:04 +01:00
Jonas Jenwald
c277e39b0b Remove the findResultsCount-check from PDFFindBar.updateResultsCount, and unnecessary defaults from the constructor
Given that `PDFFindBar` is written *specifically* for the default viewer, rather than general usage (as opposed to the `PDFFindController`), we should be able to simply assume that the `findResultsCount` DOM-element is always present. Even more so, when we're purposely not doing any similar checks for other DOM-elements in this code.

Also, remove unnecessary `null` defaults for the various DOM-element options in the constructor, since the code simply assumes that all of the relevant DOM-elements are in fact available.
2021-02-25 16:05:07 +01:00
Jonas Jenwald
df931ef685 Move the opening of PDF file attachments into the DownloadManager-implementations
Note how the `PDFAttachmentViewer` handles PDF file attachments specially, by opening them in a new window/tab, rather than forcing them to be downloaded. This is done to improve the overall UX, since browsers in general are able to handle PDF files internally.
However, for file *annotations* we're currently not attempting to do the same thing and are instead just downloading them directly. In order to unify the behaviour, without having to duplicate a lot of code, the opening of PDF file attachments is thus moved into a new `DownloadManager.openOrDownloadData` method.
2021-02-23 13:44:23 +01:00
Tim van der Meij
4619b1b568
Merge pull request #12997 from Snuffleupagus/metadata-worker
Move the Metadata parsing to the worker-thread
2021-02-17 20:57:46 +01:00
Jonas Jenwald
cc3a6563ee Move the Metadata parsing to the worker-thread
The only reason, as far as I can tell, for parsing the Metadata on the main-thread is how it was originally implemented. When Metadata support was first implemented, it utilized the [`DOMParser`](https://developer.mozilla.org/en-US/docs/Web/API/DOMParser) which isn't available in workers.
Today, with the custom XML-parser being used, that's no longer an issue and it seems reasonable to move the Metadata parsing to the worker-thread[1], since that's where all parsing should happen (for performance reasons).

Based on these changes, we'll be able to reduce the now unnecessary duplication of the XML-parser (and related code) in both of the *built* `pdf.js`/`pdf.worker.js` files.

Finally, this patch changes the `_repair` method to use "Array + join" rather than string concatenation.

---
[1] This needed the previous patch, to enable sending of `Map`s between threads with workers disabled.
2021-02-17 13:12:01 +01:00
Jonas Jenwald
0a28e51e40 Simplify the default value handling of renderInteractiveForms in the viewer components
I happened to look at this code, and I can't for the life of me figure out why I didn't just implement it like this patch in the first place (since the current format feels overly verbose).
2021-02-17 10:47:55 +01:00
Jonas Jenwald
9887644702 Stop showing the fallback bar for "errorFontMissing" errors (PR 11218 follow-up)
*This is somewhat similar to PR 12931.*

For PDF documents where fonts are completely missing in the /Resources dictionaries, there's basically no "correct" way of rendering the document.
Hence it's very unlikely that another PDF viewer will do a better job than PDF.js in these cases, and consequently it seems highly questionable if the fallback bar really helps here.
2021-02-16 16:29:13 +01:00
Tim van der Meij
f892c00275
Merge pull request #12991 from Snuffleupagus/viewer-Firefox-rm-misc-code
Stop including unused/unnecessary code in the viewer, for `MOZCENTRAL`-builds
2021-02-14 15:17:16 +01:00
Jonas Jenwald
209fe60472 Use a more compact format for the fallback EventBus-listeners in PDFViewerApplication_initializeJavaScript
Given that these event listeners should essentially never be needed, but are included simply to avoid breakage in edge-cases, it can't hurt to make this code slightly less verbose.
2021-02-14 12:37:37 +01:00
Jonas Jenwald
48f4580991 A couple of small BaseViewer tweaks
- Mark `BaseViewer.initializeScriptingEvents` as an `async` method, since that's actually how it's being used in the default viewer (see `PDFViewerApplication-_initializeJavaScript`).

 - Change `BaseViewer._pageWidthScaleFactor` to access the *internal* scroll/spread-modes directly, rather than using the getters, since that's consistent with the rest of the code (and not just for these properties).
2021-02-14 12:32:50 +01:00
Jonas Jenwald
4c107d8d7c Remove the useless PresentationModeState.CHANGING-case in PDFCursorTools (PR 12788 follow-up)
For reasons that I now can't for the life of me understand, I included handling of the `PresentationModeState.CHANGING`-case despite it not actually doing anything.
2021-02-14 10:39:49 +01:00
Jonas Jenwald
1ca816d724 Directly use requestIdleCallback in MOZCENTRAL-builds
Given the following compatibility information, we really shouldn't need to check for the availability of `requestIdleCallback` in Firefox; see https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback#browser_compatibility
2021-02-14 10:39:42 +01:00
Jonas Jenwald
7f8a9b12d9 Stop including the "errorWrapper" HTML code in MOZCENTRAL-builds
Given that these HTML elements are not being used at all in `MOZCENTRAL`-builds, note the preprocessor check in `PDFViewerApplication._otherError`, we obviously don't need the HTML code either.
2021-02-14 10:39:34 +01:00
Tim van der Meij
d5cad9ad3f
Merge pull request #12981 from Snuffleupagus/app-localizeMessage
Collect the l10n error/warning message lookup, in `web/app.js`, in a new helper method
2021-02-12 00:14:05 +01:00
Jonas Jenwald
4733f163e8 Replace a few new Date().getTime() instances with Date.now()
The former format is not only more verbose, but it's also *slightly* less efficient since it creates a new `Date` object.
2021-02-11 23:00:42 +01:00
Jonas Jenwald
fe3f074f6d Collect the l10n error/warning message lookup, in web/app.js, in a new helper method
Some of the localization strings (e.g. "loading_error") are repeated multiple times throughout the `web/app.js` file, which means that we need to duplicate the fallback strings as well. Furthermore, the signature of the `IL10n.get` method makes the call-sites quite verbose.

By adding a new helper method, in `PDFViewerApplication`, we're able to gather the localization fallback strings in one central spot in `web/app.js` and also make the lookup of the error/warning messages more compact.
2021-02-11 12:30:53 +01:00
Jonas Jenwald
25b581c2a9 Slightly simplify the parameter handling in initPassiveLoading.onOpenWithURL 2021-02-10 18:13:44 +01:00
Jonas Jenwald
b375a867eb Use arrow functions in PDFViewerApplication.initPassiveLoading
This code is *very* old and it even predates the existence of arrow functions. Hence we can now reduce the overall verbosity by not having to explicitly spell out `PDFViewerApplication` everywhere.
2021-02-10 18:13:43 +01:00
Jonas Jenwald
31098c404d
Use Math.hypot, instead of Math.sqrt with manual squaring (#12973)
When the PDF.js project started `Math.hypot` didn't exist yet, and until recently we still supported browsers (IE 11) without a native `Math.hypot` implementation; please see this compatibility information: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/hypot#browser_compatibility

Furthermore, somewhat recently there were performance improvements of `Math.hypot` in Firefox; see https://bugzilla.mozilla.org/show_bug.cgi?id=1648820

Finally, this patch also replaces a couple of multiplications with the exponentiation operator.
2021-02-10 12:28:49 +01:00
Tim van der Meij
3a2c259b57
Merge pull request #12972 from Snuffleupagus/pr-12354-followup
[GENERIC viewer] Skip the `iframe`-case when checking if the `container` div, on `BaseViewer`-instances, is absolutely positioned (PR 12354 follow-up)
2021-02-10 00:18:02 +01:00
Jonas Jenwald
32a4a30f3a Remove the contentmenu usage, from PresentationMode, since it's no longer working
This feature was Firefox-specific, and it's now been removed from the HTML specification and it's disabled by default starting with Firefox 85. Hence it seems completely unnecessary to keep this code in the default viewer.

Please refer to https://groups.google.com/g/mozilla.dev.platform/c/tc11BCenm2c and the resources that it links to.
2021-02-09 14:29:48 +01:00
Jonas Jenwald
9fa20ad8c5 [GENERIC viewer] Skip the iframe-case when checking if the container div, on BaseViewer-instances, is absolutely positioned (PR 12354 follow-up)
Given that `getComputedStyle` only works on visible elements, the result of PR 12354 is that if the viewer is placed in a *hidden* `iframe` the viewer will now be broken. This obviously wasn't the intention of that PR, hence I believe that we should limit the `position: absolute;` check slightly to avoid this.
2021-02-09 12:07:20 +01:00
Tim van der Meij
884c65c602
Merge pull request #12971 from nt1m/bool-attrs
Use DOM hidden property instead of attribute methods
2021-02-08 20:14:44 +01:00
Tim Nguyen
2ca886baee Use DOM hidden property instead of attribute methods 2021-02-08 00:21:49 +01:00
Jonas Jenwald
27727234ba Split PDFViewerApplication.error into two methods, for PDF document loading/parsing errors vs other errors (PR 11647 follow-up)
With these changes, we can easily unblock the "load" event regardless of where an error occurred.
2021-02-07 22:28:53 +01:00
Tim van der Meij
6263a21fb5
Merge pull request #12961 from Snuffleupagus/web-optional-chaining
Use optional chaining, where possible, in the `web/`-folder
2021-02-06 19:27:15 +01:00
Tim van der Meij
d2a21a1171
Merge pull request #12941 from justinribeiro/resolve-button-aria-expanded
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and aria-controls state
2021-02-06 19:16:48 +01:00
Justin Ribeiro
374da648dd
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and
aria-controls state

In testing, screen readers such as JAWS have trouble understanding the expanded state of the buttons that expand hidden menus due to lacking aria-expanded attribute. Also, given that the buttons do not contain the controlled/shown element, they should also define the aria-controls attribute with associated element id per https://www.w3.org/TR/wai-aria-1.1/#aria-expanded

This fixes adds these requirements for the sidebar, find, and secondary toolbar buttons.
2021-02-05 16:08:29 -08:00
Jonas Jenwald
08c23c12dc [Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553) 2021-02-05 22:01:57 +01:00
Jonas Jenwald
063a072742 Use optional chaining, where possible, in the web/-folder
By using optional chaining, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining, it's possible to reduce unnecessary code-repetition in many cases.
2021-02-05 17:50:11 +01:00
Jonas Jenwald
dc19965d78 Slightly re-factor how the BaseViewer/PDFThumbnailViewer handle page labels internally, to make the null default value clearer
Currently it's not *immediately* clear from the code itself, unless you look at the definition of `this._pageLabels`, that the default value is `null`.[1]
We can improve this, and also reduce the amount of code, by using modern ECMAScript features such as optional chaining and nullish coalescing.

---
[1] Keep in mind that an *empty* string is actually a valid page label, according to the PDF specification.
2021-02-05 17:50:07 +01:00
Jonas Jenwald
d1586bbbe7 Don't focus the PasswordPrompt input-field on load, when the viewer is embedded in e.g. an iframe (issue 12951)
Given that we don't focus the viewer *itself* (among other things) when the viewer is embedded, I suppose that it makes some sense to not focus the `PasswordPrompt` input-field either on load.
In order to improve the overall UX here, if an *incorrect* password was provided we'll still focus the input-field.

Fixes 12951 (assuming we care to do so, of course).
2021-02-03 15:48:40 +01:00
Jonas Jenwald
1c802e0e6c Remove prefixed fullscreen properties/methods from the MOZCENTRAL builds
The unprefixed version of the fullscreen API has been enabled for quite some time in Firefox, see below, hence we can (slightly) clean-up the relevant code.

 - https://developer.mozilla.org/en-us/docs/Web/API/Document/fullscreenEnabled#browser_compatibility
 - https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullScreen#browser_compatibility
2021-01-31 13:45:14 +01:00
Jonas Jenwald
5a522a5c71 Stop showing the fallback bar for "errorFontLoadNative" errors (PR 10539 follow-up)
With PR 10539, we'll now always attempt to fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). Generally speaking, these errors are the result of insufficient validation in the PDF.js font code, however in almost all cases we've seen thus far our built-in font renderer manages just fine.
However, we still trigger the `onUnsupportedFeature` reporting, which in Firefox causes the fallback bar to be displayed. Given that, in a majority of cases[1], things look fine it seems unfortunate to bother the user with the fallback bar here.

Note that even though we no longer show the fallback bar in this case, we still report telemetry as before.

---
[1] The only *known* case where things aren't fine with the built-in font renderer is issue 10232, however that document is sufficiently broken that there's a couple of other things that will trigger the fallback bar.
2021-01-29 16:48:51 +01:00
Jonas Jenwald
a2b592f4a2 Add previous/next-page functionality that takes scroll/spread-modes into account (issue 11946)
- For wrapped scrolling, we unfortunately need to do a fair bit of parsing of the *current* page layout. Compared to e.g. the spread-modes, where we can easily tell how the pages are laid out, with wrapped scrolling we cannot tell without actually checking. In particular documents with varying page sizes require some care, since we need to check all pages on the "row" of the current page are visible and that there aren't any "holes" present. Otherwise, in the general case, there's a risk that we'd skip over pages if we'd simply always advance to the previous/next "row" in wrapped scrolling.

 - For horizontal scrolling, this patch simply maintains the current behaviour of advancing *one* page at a time. The reason for this is to prevent inconsistent behaviour for the next and previous cases, since those cannot be handled identically. For the next-case, it'd obviously be simple to advance to the first not completely visible page. However for the previous-case, we'd only be able to go back *one* page since it's not possible to (easily) determine the page layout of non-visible pages (documents with varying page sizes being a particular issue).

 - For vertical scrolling, this patch maintains the current behaviour by default. When spread-modes are being used, we'll now attempt to advance to the next *spread*, rather than just the next page, whenever possible. To prevent skipping over a page, this two-page advance will only apply when both pages of the current spread are visible (to avoid breaking documents with varying page sizes) and when the second page in the current spread is fully visible *horizontally* (to handle larger zoom values).

In order to reduce the performance impact of these changes, note that the previous/next-functionality will only call `getVisibleElements` for the scroll/spread-modes where that's necessary and that "normal" vertical scrolling is thus unaffected by these changes.

To support these changes, the `getVisibleElements` helper function will now also include the `widthPercent` in addition to the existing `percent` property.
The `PDFViewer._updateHelper` method is changed slightly w.r.t. updating the `currentPageNumber` for the non-vertical/spread modes, i.e. won't affect "normal" vertical scrolling, since that helped simplify the overall calculation of the page advance.

Finally, these new `BaseViewer` methods also allow (some) simplification of previous/next-page functionality in various viewer components.

*Please note:* There's one thing that this patch does not attempt to change, namely disabling of the previous/next toolbarButtons respectively the firstPage/lastPage secondaryToolbarButtons. The reason for this is that doing so would add quite a bit of complexity in general, and if for some reason `BaseViewer._getPageAdvance` would get things wrong we could end up incorrectly disabling the buttons. Hence it seemed overall safer to *not* touch this, and accept that the buttons won't be `disabled` despite in some edge-cases no further scrolling being possible.
2021-01-22 21:38:15 +01:00
Jonas Jenwald
38c9f1a37a Enable the Stylelint shorthand-property-no-redundant-values rule
Note that these changes were done automatically, using `gulp lint --fix`; this rule will help avoid unnecessary repetition in the CSS.

Please find additional details about the Stylelint rule at https://stylelint.io/user-guide/rules/shorthand-property-no-redundant-values
2021-01-22 14:36:02 +01:00
Jonas Jenwald
e997f60656 Only display a notification on the sidebarToggle-button, and not the individual view-buttons (PR 7959 follow-up)
The whole purpose of showing a notification on the `sidebarToggle` button, when the sidebar is closed, was to give users *some* kind of indication that the PDF document contains outline/attachments/layers without having to manually open the sidebar to check.
However, in the implementation in PR 7959, I also added notifications for each view-buttons in the sidebar. Looking back at this, I've always questioned the value of the last part, since the view-buttons already have a `disabled`-state which shows if they're available or not. Hence we're actually, in a sense, duplicating notifications for the outline/attachments/layers-buttons without adding (in my opinion) all that much overall value.

All-in-all, I'm thus proposing that we only display the notification on the `sidebarToggle`-button itself, since that should really be sufficient here, which also allows us to simplify the relevant code a fair bit.
2021-01-18 11:36:42 +01:00
Tim van der Meij
dcd1589b2c
Merge pull request #12855 from Snuffleupagus/find-normalization
[api-minor] Highlight search results correctly for normalized text (PR 9448)
2021-01-12 22:04:10 +01:00
Jonas Jenwald
f1749f03e3 Ensure that PDFViewerApplication.close has a *consistent* return value 2021-01-12 20:28:52 +01:00
Jonas Jenwald
13742eb82d Inlude the JS actions for the page when dispatching the "pageopen"-event in the BaseViewer
Note first of all how the `PDFDocumentProxy.getJSActions` method in the API caches the result, which makes repeated lookups cheap enough to not really be an issue.
Secondly, with the previous patch, we're now only dispatching "pageopen"/"pageclose"-events when there's actually a sandbox that listens for them.

All-in-all, with these changes we can thus simplify the default-viewer "pageopen"-event handler a fair bit.
2021-01-12 20:28:50 +01:00
Ross Johnson
6dae2677d5 [api-minor] Highlight search results correctly for normalized text (PR 9448)
This patch is a rebased *and* refactored version of PR 9448, such that it applies cleanly given that `PDFFindController` has changed since that PR was opened; obviously keeping the original author information intact.

This patch will thus ensure that e.g. fractions, and other things that we normalize before searching, will still be highlighted correctly in the textLayer.

Furthermore, this patch also adds basic unit-tests for this functionality.

*Note:* The `[api-minor]` tag is added, since third-party implementations of the `PDFFindController` must now always use the `pageMatchesLength` property to get accurate length information (see the `web/text_layer_builder.js` changes).

Co-authored-by: Ross Johnson <ross@mazira.com>
Co-authored-by: Jonas Jenwald <jonas.jenwald@gmail.com>
2021-01-12 18:08:08 +01:00
Jonas Jenwald
a882a85446 Fix the initialization/resetting of scripting-related events in the BaseViewer
The "pageopen"/"pageclose"-events are only necessary if, and only if, there's actually a sandbox to dispatch the events in. Hence we shouldn't dispatch those events unconditionally, as soon as `enableScripting` is set, but rather initialize that functionality only when needed.

Furthermore, in `web/app.js`, there's currently a bug since we're attempting to *manually* simulate a "pageopen"-event for a page that may not actually have been rendered at the time. With the modified `BaseViewer.initializeScriptingEvents` method, we'll now dispatch a correct "pageopen"-event here.
2021-01-12 14:28:09 +01:00
calixteman
1de1ae0be6
Merge pull request #12838 from calixteman/authors
[api-minor] Change the "dc:creator" Metadata field to an Array
2021-01-12 02:44:58 -08:00
Calixte Denizet
43d5512f5c [api-minor] Change the "dc:creator" Metadata field to an Array
- add scripting support for doc.info.authors
 - doc.info.metadata is the raw string with xml code
2021-01-11 21:34:07 +01:00
Tim van der Meij
36e6ae5b2f
Correctly align annotation content in horizontal/spread scrolling modes
Not only was long text in popups no longer wrapped correctly, the
alignment was also center instead of left (or right, depending on the
locale used) for both text in popups and the other parts within the
annotation's section, such as the icon.
2021-01-10 18:58:13 +01:00
Jonas Jenwald
246a6f9d13 Enable the Stylelint length-zero-no-unit rule
Note that these changes were done automatically, using `gulp lint --fix`.
With this rule, we'll thus enforce a *consistent* formatting of zero-lengths in our CSS files.

Please find additional details about the Stylelint rule at https://stylelint.io/user-guide/rules/length-zero-no-unit
2021-01-10 14:09:36 +01:00
Jonas Jenwald
ccbee6d2be Remove unnecessary dir-dependent CSS rules, and simplify som findbar-button rules (PR 11077 follow-up)
With the updated default viewer UI, some `dir`-dependent CSS rules are now redundant since *identical* rules are being specified for both LTR and RTL mode; after PR 12807 landed I've found even more of these cases.

Note in particular that the findbar-button rules can be simplified quite a bit, since there's a fair amount of unnecessary duplication in the CSS.
2021-01-10 13:30:36 +01:00
Jonas Jenwald
81525fd446 Use ESLint to ensure that exports are sorted alphabetically
There's built-in ESLint rule, see `sort-imports`, to ensure that all `import`-statements are sorted alphabetically, since that often helps with readability.
Unfortunately there's no corresponding rule to sort `export`-statements alphabetically, however there's an ESLint plugin which does this; please see https://www.npmjs.com/package/eslint-plugin-sort-exports

The only downside here is that it's not automatically fixable, but the re-ordering is a one-time "cost" and the plugin will help maintain a *consistent* ordering of `export`-statements in the future.
*Note:* To reduce the possibility of introducing any errors here, the re-ordering was done by simply selecting the relevant lines and then using the built-in sort-functionality of my editor.
2021-01-09 20:37:51 +01:00
Jani Pehkonen
492a8171b3 Add an icon for the "find/highlight the current outlineItem" functionality 2021-01-09 16:09:46 +01:00
Jonas Jenwald
5729c0b32f Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050)
This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned.
*Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree.

Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents.
In an attempt to reduce the performance impact, the following steps are taken here:

 - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization.

 - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button.

 - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature.

 - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents.

Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent.

---
[1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer.

[2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2021-01-09 16:09:44 +01:00
Jonas Jenwald
373230185a Unconditionally initialize the this._pageOpenPendingSet in BaseViewer._initializeScriptingEvents (PR 12747 follow-up)
With the code dispatching a "pageopen" event on the existing (general) `BaseViewer` event "pagesinit", in practice this means that the `Set` is always being created. Hence we can simplify the method overall, by always initializing the `this._pageOpenPendingSet` property.
2021-01-07 23:11:31 +01:00
Jonas Jenwald
32b0e00ba7 Don't dispatch "pageclose" events if a "pageopen" wasn't dispatched for the page (PR 12747 follow-up)
Given that "pageopen" events are not guaranteed to occur, if the page becomes inactive *before* it finishes rendering, we should probably also avoid dispatching a "pageclose" event in that case to avoid confusing/inconsistent state in any event handlers.
2021-01-07 23:11:31 +01:00
Tim van der Meij
ac5168a23f
Merge pull request #12822 from Snuffleupagus/scripting-contentLength
Improve the `PDFViewerApplication._contentLength` handling in the viewer, related mostly to scripting
2021-01-07 23:02:53 +01:00
Jonas Jenwald
7d3632d5d5 Improve the PDFViewerApplication._contentLength handling in the viewer, related mostly to scripting
Ensure that `PDFViewerApplication._contentLength` is always updated with the *correct* length, as returned by `PDFDocumentProxy.getDownloadInfo`, and only let the `PDFViewerApplication._initializeMetadata` method overwrite if it's not already been set.

Finally, in `PDFViewerApplication._initializeJavaScript`, the fallback `_contentLength` handling is now moved to just after the fallback `documentInfo` handling, such that all the fallback code is in one place within the method.
2021-01-07 10:33:48 +01:00
Calixte Denizet
6523f8880b JS -- Plug PageOpen and PageClose actions 2021-01-06 13:31:15 +01:00