Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b135dadb17
pdf.js/web/app.js

3293 lines
101 KiB
JavaScript
Raw Normal View History

Change to the Apache v2 license.
2012-09-01 07:48:21 +09:00
/* Copyright 2012 Mozilla Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Convert the files in the `/web` folder to ES6 modules Note that as discussed on IRC, this makes the viewer slightly slower to load *only* in `gulp server` mode, however the difference seem slight enough that I think it will be fine.
2017-03-28 08:07:27 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
animationStarted,
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-07 21:04:41 +09:00
apiPageLayoutToViewerModes,
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 08:15:03 +09:00
apiPageModeToSidebarView,
Move the regular expression, used with auto printing in the viewer, to `web/ui_utils.js` and also use it in the API unit-tests Rather than having a copy of this regular expression in the `test/unit/api_spec.js` file, with a comment about keeping it up-to-date with the code in the viewer (note the incorrect file reference as well), we can just import it instead to simplify all of this.
2019-12-27 00:13:49 +09:00
AutoPrintRegExp,
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
CursorTool,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
DEFAULT_SCALE_VALUE,
Fixed keydown event handling problem with shadow DOM. Editable elements in shadow DOMs can not be detected in old version.
2020-09-23 13:59:19 +09:00
getActiveOrFocusedElement,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
isValidRotation,
isValidScrollMode,
isValidSpreadMode,
Bug 1392361 - Fix zooming sensitivity on macOS The original code would get a long sequence of miniscule "tick" values while pinch-zooming, and each tick value would cause a 1.1x zoom. So even the smallest pinch gesture on a trackpad would cause high amounts of zoom. This patch accumulates the wheel deltas until they reach an integer threshold (with a tweak of the scaling factor to make it feel more natural) at which point it triggers the zoom based on the integer component of the accumulated delta. The fractional part is retained in the accumulator.
2020-08-13 03:30:45 +09:00
normalizeWheelEventDirection,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
parseQueryString,
ProgressBar,
RendererType,
Move the `Default{...}LayerFactory` into a new `web/default_factory.js` file This patch, first of all, removes circular dependencies in the TypeScript definitions. Secondly, it also moves `RenderingStates` into `web/ui_utils.js` to break another type-dependency and directly use the `XfaLayerBuilder` during XFA-printing. Finally, note that this patch *slightly* reduces the size of the default viewer (e.g. in the `MOZCENTRAL` build) by not having to bundle code which is completely unused.
2021-12-15 21:54:29 +09:00
RenderingStates,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
ScrollMode,
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.
2020-12-25 20:57:43 +09:00
SidebarView,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
SpreadMode,
TextLayerMode,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./ui_utils.js";
Convert a number of `import * as pdfjsLib from 'pdfjs-web/pdfjs';` cases to only specify the necessary imports Rather than always importing everything from the `web/pdfjs.js`, similar to all other imports we can just choose what we actually need.
2017-03-28 17:15:02 +09:00
import {
[editor] Introduce a proper `annotationEditorMode` option/preference (PR 15075 follow-up) This replaces the boolean `annotationEditorEnabled` option/preference with a "proper" `annotationEditorMode` one. This way it's not only possible for the user to control if Editing is enabled/disabled, but also which *specific* Editing-mode should become enabled upon PDF document load. Given that Editing is not enabled/released yet, I cannot imagine that changing the name and type of the option/preference should be an issue.
2022-06-29 18:13:03 +09:00
AnnotationEditorType,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
build,
Add a `PDFViewerApplication.initializedPromise` property to allow (easier) tracking of when the default viewer has been initialized This complements the existing `PDFViewerApplication.initialized` boolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized. }) }); ``` Note that in order to avoid manually tracking the initialization state *twice*, this implementation purposely uses the `PromiseCapability` functionality to handle both `PDFViewerApplication.initialized` and `PDFViewerApplication.initializedPromise` internally.
2020-02-17 20:49:56 +09:00
createPromiseCapability,
Fix pinch-to-zoom on mac for the Firefox builtin viewer In the mac case we don't want to care about the scaleFactor threshold because else if too big another move could start and then subsequent events aren't considered as wheel events. It isn't really ideal and at some point we'll need to find a way at least for the Firefox case to get the real events instead of the fake wheel ones.
2023-02-08 22:31:28 +09:00
FeatureTest,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getDocument,
getFilenameFromUrl,
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-16 19:56:31 +09:00
getPdfFilenameFromUrl,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
GlobalWorkerOptions,
InvalidPDFException,
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
isDataScheme,
[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-24 21:02:58 +09:00
isPdfFile,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
loadScript,
MissingPDFException,
OPS,
PDFWorker,
shadow,
UnexpectedResponseException,
version,
} from "pdfjs-lib";
[editor] Introduce a proper `annotationEditorMode` option/preference (PR 15075 follow-up) This replaces the boolean `annotationEditorEnabled` option/preference with a "proper" `annotationEditorMode` one. This way it's not only possible for the user to control if Editing is enabled/disabled, but also which *specific* Editing-mode should become enabled upon PDF document load. Given that Editing is not enabled/released yet, I cannot imagine that changing the name and type of the option/preference should be an issue.
2022-06-29 18:13:03 +09:00
import { AppOptions, OptionKind } from "./app_options.js";
import { AutomationEventBus, EventBus } from "./event_utils.js";
[api-minor] Move `addLinkAttributes` and `LinkTarget` into the viewer As part of the changes/improvement in PR 14092, we're no longer using the `addLinkAttributes` directly in e.g. the AnnotationLayer-code. Given that the helper function is now *only* used in the viewer, hence it no longer seems necessary to expose it through the official API. *Please note:* It seems somewhat unlikely that third-party users were relying *directly* on the helper function, which is why it's not being exported as part of the viewer components. (If necessary, we can always change this later on.)
2022-01-03 21:36:49 +09:00
import { LinkTarget, PDFLinkService } from "./pdf_link_service.js";
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
import { AnnotationEditorParams } from "web-annotation_editor_params";
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
import { OverlayManager } from "./overlay_manager.js";
import { PasswordPrompt } from "./password_prompt.js";
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
import { PDFAttachmentViewer } from "web-pdf_attachment_viewer";
import { PDFCursorTools } from "web-pdf_cursor_tools";
import { PDFDocumentProperties } from "web-pdf_document_properties";
import { PDFFindBar } from "web-pdf_find_bar";
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
import { PDFFindController } from "./pdf_find_controller.js";
import { PDFHistory } from "./pdf_history.js";
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
import { PDFLayerViewer } from "web-pdf_layer_viewer";
import { PDFOutlineViewer } from "web-pdf_outline_viewer";
import { PDFPresentationMode } from "web-pdf_presentation_mode";
Move the `Default{...}LayerFactory` into a new `web/default_factory.js` file This patch, first of all, removes circular dependencies in the TypeScript definitions. Secondly, it also moves `RenderingStates` into `web/ui_utils.js` to break another type-dependency and directly use the `XfaLayerBuilder` during XFA-printing. Finally, note that this patch *slightly* reduces the size of the default viewer (e.g. in the `MOZCENTRAL` build) by not having to bundle code which is completely unused.
2021-12-15 21:54:29 +09:00
import { PDFRenderingQueue } from "./pdf_rendering_queue.js";
[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 08:15:18 +09:00
import { PDFScriptingManager } from "./pdf_scripting_manager.js";
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
import { PDFSidebar } from "web-pdf_sidebar";
import { PDFSidebarResizer } from "web-pdf_sidebar_resizer";
import { PDFThumbnailViewer } from "web-pdf_thumbnail_viewer";
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
import { PDFViewer } from "./pdf_viewer.js";
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
import { SecondaryToolbar } from "web-secondary_toolbar";
import { Toolbar } from "web-toolbar";
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
import { ViewHistory } from "./view_history.js";
Introduces UMD headers to the web/ folder.
2016-04-09 02:34:27 +09:00
Don't wait arbitrary long for all pages to be resolved before attempting to re-apply the initial position on load (PR 6318 follow-up) With the current code, the location in the viewer could change *well* after the user has started to interact with the viewer (for very large and/or slow loading documents). Attempt to reduce the likelyhood of that happening, by adding an upper bound to the time spent waiting before attempting to re-apply the initial position.
2018-06-26 21:08:04 +09:00
const FORCE_PAGES_LOADED_TIMEOUT = 10000; // ms
Attempt to ignore mouse wheel zooming during tab switches (bug 1503412) This patch re-factors, and extends, the already existing `zoomDisabledTimeout` used during mouse wheel zooming. Unfortunately I haven't got the required hardware to actually test this patch, but there's a decent chance that it will fix, or at least reduce, the problems reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1503412.
2018-12-12 21:46:47 +09:00
const WHEEL_ZOOM_DISABLED_TIMEOUT = 1000; // ms
Change to priority rendering.
2012-06-19 01:48:47 +09:00
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts. Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part. At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof. As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately. Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
const ViewOnLoad = {
UNKNOWN: -1,
PREVIOUS: 0, // Default value.
INITIAL: 1,
};
Add a new preference, `viewerCssTheme`, to allow forcing the use of the light/dark viewer CSS themes (issue 12290) While this does work pretty well in my quick testing, it's *very much* a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a `@media (prefers-color-scheme: dark) {...}` block. The solution implemented here is thus to *edit* the viewer CSS, by either removing the entire `@media ...` block in light-mode or by ensuring that its rules become *unconditionally* applied in dark-mode. To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the `viewerCssTheme` preference will *only* be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)
2020-11-15 21:29:50 +09:00
const ViewerCssTheme = {
AUTOMATIC: 0, // Default value.
LIGHT: 1,
DARK: 2,
};
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
class DefaultExternalServices {
constructor() {
throw new Error("Cannot initialize DefaultExternalServices.");
}
static updateFindControlState(data) {}
static updateFindMatchesCount(data) {}
static initPassiveLoading(callbacks) {}
static reportTelemetry(data) {}
Remove the unused `DefaultExternalServices.createDownloadManager` options (PR 12191 follow-up)
2022-12-03 20:52:36 +09:00
static createDownloadManager() {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new Error("Not implemented: createDownloadManager");
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
}
static createPreferences() {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new Error("Not implemented: createPreferences");
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
}
static createL10n(options) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new Error("Not implemented: createL10n");
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
}
Pass in the "sandboxBundleSrc" option when calling `DefaultExternalServices.createScripting` Similar to e.g. the "locale" option, this in *only* done for those build-targets where the "sandboxBundleSrc" is actually defined. With these changes we can remove an `AppOptions` dependency from the `web/generic_scripting.js` file, thus limiting *direct* `AppOptions` usage in the default viewer files.
2020-12-20 20:24:26 +09:00
static createScripting(options) {
Re-factor/re-name the `scripting` getter, on the `externalServices`-implementations, to a `createScripting` method Given that the GENERIC default viewer supports opening more than one document, and that a unique scripting-instance is now used for each document, the changes made in this patch seem appropriate.
2020-12-08 02:23:34 +09:00
throw new Error("Not implemented: createScripting");
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
static get supportsPinchToZoom() {
return shadow(this, "supportsPinchToZoom", true);
}
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
static get supportsIntegratedFind() {
return shadow(this, "supportsIntegratedFind", false);
}
static get supportsDocumentFonts() {
return shadow(this, "supportsDocumentFonts", true);
}
static get supportedMouseWheelZoomModifierKeys() {
return shadow(this, "supportedMouseWheelZoomModifierKeys", {
ctrlKey: true,
metaKey: true,
});
}
[api-minor] Remove the `eventBusDispatchToDOM` option/preference, and thus the general ability to dispatch "viewer components" events to the DOM This functionality was only added to the default viewer for backwards compatibility and to support the various PDF viewer tests in mozilla-central, with the intention to eventually remove it completely. While the different mozilla-central tests cannot be *easily* converted from DOM events, it's however possible to limit that functionality to only MOZCENTRAL builds *and* when tests are running. Rather than depending of the re-dispatching of internal events to the DOM, the default viewer can instead be used in e.g. the following way: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized, and its properties can be accessed. PDFViewerApplication.eventBus.on("pagerendered", function(event) { console.log("Has rendered page number: " + event.pageNumber); }); }); }); ```
2020-02-27 23:25:33 +09:00
static get isInAutomation() {
return shadow(this, "isInAutomation", false);
}
[Editor] Dispatch an event when some global states are changing - this way the context menu in Firefox can take into account what we have in the clipboard, if an editor is selected, ... - when the user will click on a context menu item, an action will be triggered, hence this patch adds what is required to handle it; - some tests will be added in the Firefox' patch.
2022-07-05 01:04:32 +09:00
static updateEditorStates(data) {
throw new Error("Not implemented: updateEditorStates");
}
[api-minor] Add an option to set the max canvas area
2023-03-07 01:16:43 +09:00
static get canvasMaxAreaInBytes() {
return shadow(this, "canvasMaxAreaInBytes", -1);
}
Re-factor the various `ExternalServices`, used in the default viewer, to classes with static methods This seems nicer overall, since it's now a bit clearer that the various build targets *extend* the default implementation.
2020-01-15 22:26:47 +09:00
}
Refactors firefoxcom dependency on app and l10n.
2016-04-14 06:21:05 +09:00
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const PDFViewerApplication = {
Making all link bookmark-able (ref #574, #428); removing always-changing hash
2011-10-02 03:54:37 +09:00
initialBookmark: document.location.hash.substring(1),
Add a `PDFViewerApplication.initializedPromise` property to allow (easier) tracking of when the default viewer has been initialized This complements the existing `PDFViewerApplication.initialized` boolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized. }) }); ``` Note that in order to avoid manually tracking the initialization state *twice*, this implementation purposely uses the `PromiseCapability` functionality to handle both `PDFViewerApplication.initialized` and `PDFViewerApplication.initializedPromise` internally.
2020-02-17 20:49:56 +09:00
_initializedCapability: createPromiseCapability(),
Moves all document.getElementById lookups into viewer.js
2016-04-22 01:39:11 +09:00
appConfig: null,
Use already downloaded data for the open with/save as dialog.
2012-06-02 06:17:09 +09:00
pdfDocument: null,
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
pdfLoadingTask: null,
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
printService: null,
Adds types definitions (jsdoc) for the PDFViewer code.
2014-09-21 02:21:49 +09:00
/** @type {PDFViewer} */
Moves viewer code into PDFViewer and some code from PageView.
2014-09-13 11:27:45 +09:00
pdfViewer: null,
Adds types definitions (jsdoc) for the PDFViewer code.
2014-09-21 02:21:49 +09:00
/** @type {PDFThumbnailViewer} */
Moves thumbs logic into PDFThumbnailViewer.
2014-09-13 04:48:44 +09:00
pdfThumbnailViewer: null,
Adds types definitions (jsdoc) for the PDFViewer code.
2014-09-21 02:21:49 +09:00
/** @type {PDFRenderingQueue} */
Moves rendering queue logic from PDFView
2014-09-16 01:18:28 +09:00
pdfRenderingQueue: null,
Refactor PDFPresentationMode to be more class-like
2015-02-04 02:09:11 +09:00
/** @type {PDFPresentationMode} */
pdfPresentationMode: null,
Refactor PDFDocumentProperties to be more class-like
2015-04-25 03:47:38 +09:00
/** @type {PDFDocumentProperties} */
pdfDocumentProperties: null,
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
/** @type {PDFLinkService} */
pdfLinkService: null,
Refactors PDFHistory. # Conflicts: # extensions/b2g/viewer.js # web/pdf_history.js # web/pdf_viewer.component.js # web/viewer.js
2015-04-27 23:04:11 +09:00
/** @type {PDFHistory} */
pdfHistory: null,
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
/** @type {PDFSidebar} */
pdfSidebar: null,
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072) By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code. Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar. However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem. Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`. *Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome. Fixes 2072.
2017-10-10 23:16:05 +09:00
/** @type {PDFSidebarResizer} */
pdfSidebarResizer: null,
Refactor how `PDFOutlineView`/`PDFAttachmentView` is initialized in viewer.js, rename the classes, and refactor their `render` methods Changes `PDFOutlineView`/`PDFAttachmentView` to be initialized once, since we're always creating them, and refactor their `render` methods to instead pass in the `outline`/`attachments`. For consistency with other "classes", the `PDFOutlineView`/`PDFAttachmentView` are renamed to `PDFOutlineViewer`/`PDFAttachmentViewer`. Also, make sure that the outline/attachments are reset when the document is closed. Currently we keep the old ones around until the `getOutline`/`getAttachments` API calls are resolved for a new document.
2016-02-21 21:36:24 +09:00
/** @type {PDFOutlineViewer} */
pdfOutlineViewer: null,
/** @type {PDFAttachmentViewer} */
pdfAttachmentViewer: null,
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
/** @type {PDFLayerViewer} */
pdfLayerViewer: null,
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
/** @type {PDFCursorTools} */
pdfCursorTools: null,
[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 08:15:18 +09:00
/** @type {PDFScriptingManager} */
pdfScriptingManager: null,
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
/** @type {ViewHistory} */
store: null,
Refactors firefoxcom dependency on app and l10n.
2016-04-14 06:21:05 +09:00
/** @type {DownloadManager} */
downloadManager: null,
Convert the overlay manager to ES6 syntax
2017-05-26 21:52:23 +09:00
/** @type {OverlayManager} */
overlayManager: null,
Convert the `Preferences` to an ES6 class
2017-04-17 20:21:11 +09:00
/** @type {Preferences} */
preferences: null,
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
/** @type {Toolbar} */
toolbar: null,
/** @type {SecondaryToolbar} */
secondaryToolbar: null,
Adds EventBus.
2016-04-26 07:57:15 +09:00
/** @type {EventBus} */
eventBus: null,
Wraps mozL10n to async calls; splits firefox and generic l10n libs.
2017-05-04 10:05:53 +09:00
/** @type {IL10n} */
l10n: null,
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
/** @type {AnnotationEditorParams} */
annotationEditorParams: null,
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
isInitialViewSet: false,
Reset `pageRotation` and `downloadComplete` in `PDFViewerApplication.close` Currently, these properties are reset in what appears to be somewhat arbitrary locations (within the `load` and `open` methods respectively). The explanation is probably that both of these properties predates the existence of any centralized clean-up code in the viewer. Hence I think that it makes sense to move the resetting of these properties to the `close` method, since that improves the overview of what's actually cleaned-up/reset when changing documents in the viewer.
2017-06-17 20:14:36 +09:00
downloadComplete: false,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
isViewerEmbedded: window.parent !== window,
url: "",
baseUrl: "",
[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-12 19:34:58 +09:00
_downloadUrl: "",
Refactor the `DownloadManager` initialization in `GENERIC`/`CHROME` builds, to avoid issues when converting the code to ES6 modules
2017-03-28 06:37:14 +09:00
externalServices: DefaultExternalServices,
Dispatch a `metadataloaded` event once the `PDFViewerApplication._initializeMetadata` method is done This will be useful in the following patch, and note that there's also an old issue (see 5765) which asked for such an event. However, given that the use-case wasn't *clearly* specified, and that we didn't have an internal use for it at the time it wasn't implemented. Also, ensure that all of the metadata-related properties are actually reset when the document is closed.
2020-12-06 20:30:33 +09:00
_boundEvents: Object.create(null),
documentInfo: null,
metadata: null,
Tweak the "filesize" handling in `PDFViewerApplication._initializeJavaScript` Another possible option here could be to use the `contentLength`, when it exists, and then using e.g. a custom event to always update the "filesize" in the sandbox "after the fact" with the result of the `getDownloadInfo`-call.
2020-12-06 21:00:34 +09:00
_contentDispositionFilename: null,
_contentLength: null,
Add support for saving forms
2020-08-04 02:44:04 +09:00
_saveInProgress: false,
Bug 1392361 - Fix zooming sensitivity on macOS The original code would get a long sequence of miniscule "tick" values while pinch-zooming, and each tick value would cause a 1.1x zoom. So even the smallest pinch gesture on a trackpad would cause high amounts of zoom. This patch accumulates the wheel deltas until they reach an integer threshold (with a tweak of the scaling factor to make it feel more natural) at which point it triggers the zoom based on the integer component of the accumulated delta. The fractional part is retained in the accumulator.
2020-08-13 03:30:45 +09:00
_wheelUnusedTicks: 0,
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
_wheelUnusedFactor: 1,
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
_touchUnusedTicks: 0,
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
_touchUnusedFactor: 1,
Convert `web/debugger.js` to a *basic* module The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures. Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer. Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally. According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations. --- [1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
_PDFBug: null,
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
_hasAnnotationEditors: false,
_title: document.title,
[api-minor] Introduce a `PrintAnnotationStorage` with *frozen* serializable data Given that printing is triggered *synchronously* in browsers, it's thus possible for scripting (in PDF documents) to modify the Annotation-data while printing is currently ongoing. To work-around that we add a new printing-specific `AnnotationStorage`, where the serializable data is *frozen* upon initialization, which the viewer can thus create/utilize during printing.
2022-06-13 20:35:58 +09:00
_printAnnotationStoragePromise: null,
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
_touchInfo: null,
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
_isCtrlKeyDown: false,
Change to priority rendering.
2012-06-19 01:48:47 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
// Called once when the document is loaded.
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
async initialize(appConfig) {
Convert the `Preferences` to an ES6 class
2017-04-17 20:21:11 +09:00
this.preferences = this.externalServices.createPreferences();
Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing e.g. the viewer components Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
2016-12-08 21:30:21 +09:00
this.appConfig = appConfig;
Refactor `PDFViewerApplication.initialize` into two methods, one that reads the Preferences and one that initializes the various viewer components
2016-12-11 07:10:08 +09:00
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
await this._initializeOptions();
Add a new preference, `viewerCssTheme`, to allow forcing the use of the light/dark viewer CSS themes (issue 12290) While this does work pretty well in my quick testing, it's *very much* a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a `@media (prefers-color-scheme: dark) {...}` block. The solution implemented here is thus to *edit* the viewer CSS, by either removing the entire `@media ...` block in light-mode or by ensuring that its rules become *unconditionally* applied in dark-mode. To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the `viewerCssTheme` preference will *only* be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)
2020-11-15 21:29:50 +09:00
this._forceCssTheme();
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
await this._initializeL10n();
Convert the only remaining consumer (in `hand_tool.js`) of the 'localized' event to use the `localized` Promise instead, and only re-dispatch the 'localized' event on the `eventBus` for `GENERIC` builds Ideally we'd remove the 'localized' event from the `eventBus`, but for backwards compatibility we keep it in `GENERIC` builds. Note that while we want to ensure that the direction attribute of the HTML is updated as soon as the `localized` Promise is resolved, we purposely wait until the viewer has been initialized to ensure that the 'localized' event will always be dispatched.
2016-12-08 22:44:12 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
this.isViewerEmbedded &&
AppOptions.get("externalLinkTarget") === LinkTarget.NONE
) {
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
// Prevent external links from "replacing" the viewer,
// when it's embedded in e.g. an <iframe> or an <object>.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
AppOptions.set("externalLinkTarget", LinkTarget.TOP);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
await this._initializeViewerComponents();
// Bind the various event handlers *after* the viewer has been
// initialized, to prevent errors if an event arrives too soon.
this.bindEvents();
this.bindWindowEvents();
// We can start UI localization now.
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const appContainer = appConfig.appContainer || document.documentElement;
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.l10n.translate(appContainer).then(() => {
// Dispatch the 'localized' event on the `eventBus` once the viewer
// has been fully initialized and translated.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.eventBus.dispatch("localized", { source: this });
Refactor `PDFViewerApplication.initialize` into two methods, one that reads the Preferences and one that initializes the various viewer components
2016-12-11 07:10:08 +09:00
});
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
Add a `PDFViewerApplication.initializedPromise` property to allow (easier) tracking of when the default viewer has been initialized This complements the existing `PDFViewerApplication.initialized` boolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized. }) }); ``` Note that in order to avoid manually tracking the initialization state *twice*, this implementation purposely uses the `PromiseCapability` functionality to handle both `PDFViewerApplication.initialized` and `PDFViewerApplication.initializedPromise` internally.
2020-02-17 20:49:56 +09:00
this._initializedCapability.resolve();
Refactor `PDFViewerApplication.initialize` into two methods, one that reads the Preferences and one that initializes the various viewer components
2016-12-11 07:10:08 +09:00
},
/**
* @private
*/
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
async _initializeOptions() {
Limit `AppOptions._hasUserOptions` to only GENERIC builds It's completely unused elsewhere, e.g. in the Firefox PDF Viewer.
2023-02-10 23:37:51 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
[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 20:26:17 +09:00
if (AppOptions.get("disablePreferences")) {
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
if (AppOptions.get("pdfBugEnabled")) {
await this._parseHashParams();
}
[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 20:26:17 +09:00
// Give custom implementations of the default viewer a simpler way to
// opt-out of having the `Preferences` override existing `AppOptions`.
return;
}
if (AppOptions._hasUserOptions()) {
console.warn(
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
"_initializeOptions: The Preferences may override manually set AppOptions; " +
[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 20:26:17 +09:00
'please use the "disablePreferences"-option in order to prevent that.'
);
}
Replace the `OVERRIDES` list in `PDFViewerApplication._readPreferences` with a `disablePreferences`, in `GENERIC` builds, `AppOption instead Rather than having a (somewhat) randomly choosen list of Preferences which `AppOptions` are allowed to override, it makes much more sense to simply add an AppOption to allow custom implementations to ignore Preferences altogether (it's also inline with the AppOption that allows the `ViewHistory` to be bypassed on load).
2018-11-29 19:31:49 +09:00
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
try {
Add an `AppOptions.setAll` method, and use it in `PDFViewerApplication._readPreferences` Given that it's generally faster to call *one* function and have it loop through an object, rather than looping through an object and calling a function for every iteration, this patch will reduce the total time spent in `PDFViewerApplication._readPreferences` ever so slightly. Also, over time we've been adding more and more preferences, rather than removing them, so using the new `AppOptions.setAll` method should be generally beneficial as well. While the effect of these changes is quite small, it does reduces the time it takes for the preferences to be fully initialized. Given the amount of asynchronous code during viewer initialization, every bit of time that we can save should thus help. Especially considering the recently added `viewerCssTheme` preference, which needs to be read very early to reduce the risk of the viewer UI "flashing" visibly as the theme changes, I figured that a couple of small patches reducing the time spend reading preferences cannot hurt.
2020-11-17 21:44:15 +09:00
AppOptions.setAll(await this.preferences.getAll());
Add type validation to the `default_preferences` generation (PR 10548 follow-up) The generated `default_preferences.json` file is necessary when initializing the Firefox preferences, which only supports certain types, hence this patch adds additional validation to help prevent run-time errors in Firefox. Given that these changes add a code-path to `AppOptions.getAll` which could throw, the `OptionKind.PREFERENCE` branch is also modified to require *exact* matching to prevent (future) errors in the viewer. Finally the conditionally defined `defaultOptions` will no longer (potentially) be considered during the `gulp default_preferences` task, to make it more difficult for them to be accidentally included.
2019-03-03 19:40:56 +09:00
} catch (reason) {
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
console.error(`_initializeOptions: "${reason.message}".`);
}
if (AppOptions.get("pdfBugEnabled")) {
await this._parseHashParams();
Add type validation to the `default_preferences` generation (PR 10548 follow-up) The generated `default_preferences.json` file is necessary when initializing the Firefox preferences, which only supports certain types, hence this patch adds additional validation to help prevent run-time errors in Firefox. Given that these changes add a code-path to `AppOptions.getAll` which could throw, the `OptionKind.PREFERENCE` branch is also modified to require *exact* matching to prevent (future) errors in the viewer. Finally the conditionally defined `defaultOptions` will no longer (potentially) be considered during the `gulp default_preferences` task, to make it more difficult for them to be accidentally included.
2019-03-03 19:40:56 +09:00
}
Refactor `PDFViewerApplication.initialize` into two methods, one that reads the Preferences and one that initializes the various viewer components
2016-12-11 07:10:08 +09:00
},
Extract parsing of debugging hash parameters into its own method in `PDFViewerApplication` In order to move viewer related options from the global `PDFJS` object and into the initialization of the relevant components, we'll need to parse the hash parameters *before* calling `PDFViewerApplication._initializeViewerComponents`.
2017-11-13 18:17:25 +09:00
/**
Return early in `PDFViewerApplication._parseHashParameters` when the hash is empty For people running e.g. Firefox with the `pdfBugEnabled` preference set, to allow quick access to debugging tools, this method will obviously run for every opened PDF file. However, in most cases the URL hash is empty and we can thus skip most of the parsing and simply return early instead.
2020-01-23 20:05:43 +09:00
* Potentially parse special debugging flags in the hash section of the URL.
Extract parsing of debugging hash parameters into its own method in `PDFViewerApplication` In order to move viewer related options from the global `PDFJS` object and into the initialization of the relevant components, we'll need to parse the hash parameters *before* calling `PDFViewerApplication._initializeViewerComponents`.
2017-11-13 18:17:25 +09:00
* @private
*/
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
async _parseHashParams() {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const hash = document.location.hash.substring(1);
Return early in `PDFViewerApplication._parseHashParameters` when the hash is empty For people running e.g. Firefox with the `pdfBugEnabled` preference set, to allow quick access to debugging tools, this method will obviously run for every opened PDF file. However, in most cases the URL hash is empty and we can thus skip most of the parsing and simply return early instead.
2020-01-23 20:05:43 +09:00
if (!hash) {
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-09 20:16:02 +09:00
return;
Return early in `PDFViewerApplication._parseHashParameters` when the hash is empty For people running e.g. Firefox with the `pdfBugEnabled` preference set, to allow quick access to debugging tools, this method will obviously run for every opened PDF file. However, in most cases the URL hash is empty and we can thus skip most of the parsing and simply return early instead.
2020-01-23 20:05:43 +09:00
}
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
const { mainContainer, viewerContainer } = this.appConfig,
params = parseQueryString(hash);
Extract parsing of debugging hash parameters into its own method in `PDFViewerApplication` In order to move viewer related options from the global `PDFJS` object and into the initialization of the relevant components, we'll need to parse the hash parameters *before* calling `PDFViewerApplication._initializeViewerComponents`.
2017-11-13 18:17:25 +09:00
Allow, optionally, using worker-modules during local development Until PR 12563 is deemed safe to land, I'd still like to be able to use worker-modules in the viewer during local development. Hence this patch which *temporarily* adds a new `workerModules` hash-parameter, only available in non-PRODUCTION mode, that allows using worker-modules in the development viewer. To enable this functionality, simply use http://localhost:8888/web/viewer.html#workerModules=true
2023-01-31 20:00:15 +09:00
if (
(typeof PDFJSDev === "undefined" || !PDFJSDev.test("PRODUCTION")) &&
params.get("workermodules") === "true"
) {
AppOptions.set("workerSrc", "../src/pdf.worker.js");
} else if (params.get("disableworker") === "true") {
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
try {
await loadFakeWorker();
} catch (ex) {
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
console.error(`_parseHashParams: "${ex.message}".`);
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("disablerange")) {
AppOptions.set("disableRange", params.get("disablerange") === "true");
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("disablestream")) {
AppOptions.set("disableStream", params.get("disablestream") === "true");
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("disableautofetch")) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
AppOptions.set(
"disableAutoFetch",
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
params.get("disableautofetch") === "true"
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("disablefontface")) {
AppOptions.set(
"disableFontFace",
params.get("disablefontface") === "true"
);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("disablehistory")) {
AppOptions.set("disableHistory", params.get("disablehistory") === "true");
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("verbosity")) {
AppOptions.set("verbosity", params.get("verbosity") | 0);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("textlayer")) {
switch (params.get("textlayer")) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "off":
AppOptions.set("textLayerMode", TextLayerMode.DISABLE);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "visible":
case "shadow":
case "hover":
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
viewerContainer.classList.add(`textLayer-${params.get("textlayer")}`);
try {
await loadPDFBug(this);
this._PDFBug.loadCSS();
} catch (ex) {
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
console.error(`_parseHashParams: "${ex.message}".`);
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
break;
Wraps mozL10n to async calls; splits firefox and generic l10n libs.
2017-05-04 10:05:53 +09:00
}
}
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
if (params.has("pdfbug")) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
AppOptions.set("pdfBug", true);
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
AppOptions.set("fontExtraProperties", true);
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
const enabled = params.get("pdfbug").split(",");
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
try {
await loadPDFBug(this);
this._PDFBug.init({ OPS }, mainContainer, enabled);
} catch (ex) {
Slightly re-factor preferences/options initialization in the viewer Given that the debugging hash-parameters will only be used when the `pdfBugEnabled` option is manually set[1], we can skip a *tiny* bit of asynchronicity for "regular" users. --- [1] Note that it's enabled by default in the development viewer, i.e. in `gulp server` mode.
2023-02-10 23:45:39 +09:00
console.error(`_parseHashParams: "${ex.message}".`);
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
// It is not possible to change locale for the (various) extension builds.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
(typeof PDFJSDev === "undefined" ||
PDFJSDev.test("!PRODUCTION || GENERIC")) &&
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
params.has("locale")
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
AppOptions.set("locale", params.get("locale"));
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Extract parsing of debugging hash parameters into its own method in `PDFViewerApplication` In order to move viewer related options from the global `PDFJS` object and into the initialization of the relevant components, we'll need to parse the hash parameters *before* calling `PDFViewerApplication._initializeViewerComponents`.
2017-11-13 18:17:25 +09:00
},
/**
* @private
*/
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
async _initializeL10n() {
Avoid reading the "disablePreferences"/"locale" options, when initializing the viewer, in extension builds These two `AppOptions` are only defined in GENERIC builds, hence it's completely unnecessary to check them in the extension builds (e.g. MOZCENTRAL and CHROME). Also, simply let the "printResolution" option be defined in all builds since it's being accessed in `web/firefox_print_service.js` as well.
2020-04-20 20:09:33 +09:00
this.l10n = this.externalServices.createL10n(
typeof PDFJSDev === "undefined" || PDFJSDev.test("!PRODUCTION || GENERIC")
? { locale: AppOptions.get("locale") }
: null
);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
const dir = await this.l10n.getDirection();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
document.getElementsByTagName("html")[0].dir = dir;
Wraps mozL10n to async calls; splits firefox and generic l10n libs.
2017-05-04 10:05:53 +09:00
},
Add a new preference, `viewerCssTheme`, to allow forcing the use of the light/dark viewer CSS themes (issue 12290) While this does work pretty well in my quick testing, it's *very much* a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a `@media (prefers-color-scheme: dark) {...}` block. The solution implemented here is thus to *edit* the viewer CSS, by either removing the entire `@media ...` block in light-mode or by ensuring that its rules become *unconditionally* applied in dark-mode. To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the `viewerCssTheme` preference will *only* be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)
2020-11-15 21:29:50 +09:00
/**
* @private
*/
_forceCssTheme() {
const cssTheme = AppOptions.get("viewerCssTheme");
if (
cssTheme === ViewerCssTheme.AUTOMATIC ||
!Object.values(ViewerCssTheme).includes(cssTheme)
) {
return;
}
try {
const styleSheet = document.styleSheets[0];
const cssRules = styleSheet?.cssRules || [];
for (let i = 0, ii = cssRules.length; i < ii; i++) {
const rule = cssRules[i];
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 19:17:42 +09:00
if (
rule instanceof CSSMediaRule &&
rule.media?.[0] === "(prefers-color-scheme: dark)"
) {
Add a new preference, `viewerCssTheme`, to allow forcing the use of the light/dark viewer CSS themes (issue 12290) While this does work pretty well in my quick testing, it's *very much* a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a `@media (prefers-color-scheme: dark) {...}` block. The solution implemented here is thus to *edit* the viewer CSS, by either removing the entire `@media ...` block in light-mode or by ensuring that its rules become *unconditionally* applied in dark-mode. To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the `viewerCssTheme` preference will *only* be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)
2020-11-15 21:29:50 +09:00
if (cssTheme === ViewerCssTheme.LIGHT) {
styleSheet.deleteRule(i);
return;
}
// cssTheme === ViewerCssTheme.DARK
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 19:17:42 +09:00
const darkRules =
/^@media \(prefers-color-scheme: dark\) {\n\s*([\w\s-.,:;/\\{}()]+)\n}$/.exec(
rule.cssText
);
Add a new preference, `viewerCssTheme`, to allow forcing the use of the light/dark viewer CSS themes (issue 12290) While this does work pretty well in my quick testing, it's *very much* a hack since as far as I can tell there's no support in the CSS specification for using e.g. a CSS variable to override a `@media (prefers-color-scheme: dark) {...}` block. The solution implemented here is thus to *edit* the viewer CSS, by either removing the entire `@media ...` block in light-mode or by ensuring that its rules become *unconditionally* applied in dark-mode. To simplify the overall implementation, since all of this does seem like somewhat of an edge-case, the `viewerCssTheme` preference will *only* be read during viewer initialization. (Similar to many other existing preferences, a reload is thus required when changing it.)
2020-11-15 21:29:50 +09:00
if (darkRules?.[1]) {
styleSheet.deleteRule(i);
styleSheet.insertRule(darkRules[1], i);
}
return;
}
}
} catch (reason) {
console.error(`_forceCssTheme: "${reason?.message}".`);
}
},
Refactor `PDFViewerApplication.initialize` into two methods, one that reads the Preferences and one that initializes the various viewer components
2016-12-11 07:10:08 +09:00
/**
* @private
*/
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
async _initializeViewerComponents() {
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 01:17:40 +09:00
const { appConfig, externalServices } = this;
Remove the `eventBus` parameter from `getViewerConfiguration` This structure contains *almost* exclusively references to DOM elements (and a couple of simple strings), rather than complete classes/functions. Hence the `eventBus`-option sticks out a fair bit, and I'd guess that it's *mostly* unused in e.g. third-party implementations. Given that we, in multiple places, mention that the default viewer shouldn't be used as-is I really don't think that we need to keep this special `eventBus`-option around. Furthermore, nowadays it's also a lot easier to (safely) access the existing `EventBus`-instance in the viewer; see https://github.com/mozilla/pdf.js/wiki/Third-party-viewer-usage#initialization-promise which shows how to listen for the default viewer being initialized (and its `eventBus` thus being available).
2022-01-06 20:09:57 +09:00
const eventBus = externalServices.isInAutomation
? new AutomationEventBus()
: new EventBus();
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.eventBus = eventBus;
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
[api-minor] Remove the `eventBusDispatchToDOM` option/preference, and thus the general ability to dispatch "viewer components" events to the DOM This functionality was only added to the default viewer for backwards compatibility and to support the various PDF viewer tests in mozilla-central, with the intention to eventually remove it completely. While the different mozilla-central tests cannot be *easily* converted from DOM events, it's however possible to limit that functionality to only MOZCENTRAL builds *and* when tests are running. Rather than depending of the re-dispatching of internal events to the DOM, the default viewer can instead be used in e.g. the following way: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized, and its properties can be accessed. PDFViewerApplication.eventBus.on("pagerendered", function(event) { console.log("Has rendered page number: " + event.pageNumber); }); }); }); ```
2020-02-27 23:25:33 +09:00
this.overlayManager = new OverlayManager();
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const pdfRenderingQueue = new PDFRenderingQueue();
[api-minor] Add an option, in `PDFDocumentProxy.cleanup`, to allow fonts to remain attached to the DOM As mentioned in the JSDoc comment, this should not be used unless you know what you're doing, since it will lead to increased memory usage. However, in some situations (e.g. SVG-rendering), we still want to be able to run general clean-up on both the main/worker-thread while keeping loaded fonts attached to the DOM.[1] As part of these changes, `WorkerTransport.startCleanup` is converted to an async method and we'll also skip clean-up when destruction has started (since it's redundant). --- [1] The SVG-rendering mode is obviously not officially supported, since it's both rather incomplete and inherently slower. However with recent changes, whereby we cache repeated images on the document rather than the page level, memory usage can be *a lot* worse than before if we never attempt to release e.g. cached image-data when the viewer is in SVG-rendering mode.
2021-04-02 19:26:39 +09:00
pdfRenderingQueue.onIdle = this._cleanup.bind(this);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.pdfRenderingQueue = pdfRenderingQueue;
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const pdfLinkService = new PDFLinkService({
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
eventBus,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
externalLinkTarget: AppOptions.get("externalLinkTarget"),
externalLinkRel: AppOptions.get("externalLinkRel"),
Add a `ignoreDestinationZoom` option/preference to allow users to preserve the current zoom level when navigating to internal destinations (issue 5064, 11606)
2020-02-17 22:04:55 +09:00
ignoreDestinationZoom: AppOptions.get("ignoreDestinationZoom"),
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
});
this.pdfLinkService = pdfLinkService;
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
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 01:17:40 +09:00
const downloadManager = externalServices.createDownloadManager();
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.downloadManager = downloadManager;
Remove the find controller setter in `web/base_viewer.js` With `PDFFindController` instances no longer (directly) depending on `BaseViewer` instances, we can pass a single `findController` when initializing a viewer, similar to other components.
2018-09-23 02:44:13 +09:00
const findController = new PDFFindController({
linkService: pdfLinkService,
eventBus,
[GV] Add an option in the find controller to update matches count only when the last page is reached (bug 1803188). In GeckoView, on an event, a callback must be executed with the result of an action, but the callback can be used only one time. So for each FindInPage event, we must trigger only one matches count update.
2022-11-09 19:09:22 +09:00
updateMatchesCountOnProgress:
[GeckoView] Introduce a development mode constant to tell the viewers apart Currently we have a couple of pre-processor checks, specifically for the GV-viewer, spread throughout the code. This works fine when *building* the viewer, however they're obviously ignored in development mode (i.e. `gulp server`). This leads to a situation where the GV development viewer, i.e. http://localhost:8888/web/viewer-geckoview.html, behaves subtly different from its built version. This could easily lead to bugs, hence this patch introduces a development mode constant to hopefully improve things here. Finally, in a follow-up to PR 15842, also ignores the `pageMode`-state since there's no sidebar available.
2023-02-08 00:07:12 +09:00
typeof PDFJSDev === "undefined"
? !window.isGECKOVIEW
: !PDFJSDev.test("GECKOVIEW"),
Remove the find controller setter in `web/base_viewer.js` With `PDFFindController` instances no longer (directly) depending on `BaseViewer` instances, we can pass a single `findController` when initializing a viewer, similar to other components.
2018-09-23 02:44:13 +09:00
});
this.findController = findController;
[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 08:15:18 +09:00
const pdfScriptingManager = new PDFScriptingManager({
eventBus,
sandboxBundleSrc:
typeof PDFJSDev === "undefined" ||
PDFJSDev.test("!PRODUCTION || GENERIC || CHROME")
? AppOptions.get("sandboxBundleSrc")
: null,
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 01:17:40 +09:00
scriptingFactory: externalServices,
[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 08:15:18 +09:00
docPropertiesLookup: this._scriptingDocProperties.bind(this),
});
this.pdfScriptingManager = pdfScriptingManager;
Support custom `pageColors` in the thumbnails (PR 14874) Currently, when non-standard `pageColors` are specified, the thumbnails will look inconsistent depending on how they're created. The thumbnails that are created by downsizing the *page* canvases will obviously use the `pageColors` as intended, however the thumbnails which are rendered *directly* will always use the default colors.
2022-05-26 16:45:05 +09:00
const container = appConfig.mainContainer,
viewer = appConfig.viewerContainer;
[editor] Introduce a proper `annotationEditorMode` option/preference (PR 15075 follow-up) This replaces the boolean `annotationEditorEnabled` option/preference with a "proper" `annotationEditorMode` one. This way it's not only possible for the user to control if Editing is enabled/disabled, but also which *specific* Editing-mode should become enabled upon PDF document load. Given that Editing is not enabled/released yet, I cannot imagine that changing the name and type of the option/preference should be an issue.
2022-06-29 18:13:03 +09:00
const annotationEditorMode = AppOptions.get("annotationEditorMode");
Use default colors only in forced-colors mode (bug 1778068)
2022-07-06 20:50:45 +09:00
const pageColors =
AppOptions.get("forcePageColors") ||
window.matchMedia("(forced-colors: active)").matches
? {
background: AppOptions.get("pageColorsBackground"),
foreground: AppOptions.get("pageColorsForeground"),
}
: null;
Support custom `pageColors` in the thumbnails (PR 14874) Currently, when non-standard `pageColors` are specified, the thumbnails will look inconsistent depending on how they're created. The thumbnails that are created by downsizing the *page* canvases will obviously use the `pageColors` as intended, however the thumbnails which are rendered *directly* will always use the default colors.
2022-05-26 16:45:05 +09:00
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.pdfViewer = new PDFViewer({
container,
viewer,
eventBus,
renderingQueue: pdfRenderingQueue,
linkService: pdfLinkService,
downloadManager,
Remove the find controller setter in `web/base_viewer.js` With `PDFFindController` instances no longer (directly) depending on `BaseViewer` instances, we can pass a single `findController` when initializing a viewer, similar to other components.
2018-09-23 02:44:13 +09:00
findController,
[api-minor] Remove the separate `enableScripting` option in `BaseViewer` Prior to PR 13042, when scripting wasn't really possible to use outside of the full viewer, the `enableScripting` option made sense. However, at this point in time having to both pass in a `PDFScriptingManager`-instance *and* set the `enableScripting`-boolean when creating a `BaseViewer`-instance feels redundant and (mostly) annoying. Hence this patch, which removes the *separate* boolean and always enables scripting when `scriptingManager` is provided. The relevant "viewer component" examples are also updated (with a comment), but in such a way that scripting support won't just break when used with the current PDF.js releases.
2021-07-29 16:53:24 +09:00
scriptingManager:
AppOptions.get("enableScripting") && pdfScriptingManager,
Only define the `renderer`-option in the GENERIC viewer Given that the SVG back-end is not defined anywhere except in GENERIC builds, we can remove a little bit of unnecessary code in e.g. the Firefox PDF Viewer.
2022-06-16 23:11:47 +09:00
renderer:
typeof PDFJSDev === "undefined" ||
PDFJSDev.test("!PRODUCTION || GENERIC")
? AppOptions.get("renderer")
: null,
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
l10n: this.l10n,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
textLayerMode: AppOptions.get("textLayerMode"),
[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-08 21:36:28 +09:00
annotationMode: AppOptions.get("annotationMode"),
[editor] Introduce a proper `annotationEditorMode` option/preference (PR 15075 follow-up) This replaces the boolean `annotationEditorEnabled` option/preference with a "proper" `annotationEditorMode` one. This way it's not only possible for the user to control if Editing is enabled/disabled, but also which *specific* Editing-mode should become enabled upon PDF document load. Given that Editing is not enabled/released yet, I cannot imagine that changing the name and type of the option/preference should be an issue.
2022-06-29 18:13:03 +09:00
annotationEditorMode,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
imageResourcesPath: AppOptions.get("imageResourcesPath"),
enablePrintAutoRotate: AppOptions.get("enablePrintAutoRotate"),
useOnlyCssZoom: AppOptions.get("useOnlyCssZoom"),
Refactor the text layer code in order to avoid to recompute it on each draw The idea is just to resuse what we got on the first draw. Now, we only update the scaleX of the different spans and the other values are dependant of --scale-factor. Move some properties in the CSS in order to avoid any updates in JS.
2022-11-22 01:15:39 +09:00
isOffscreenCanvasSupported: AppOptions.get("isOffscreenCanvasSupported"),
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
maxCanvasPixels: AppOptions.get("maxCanvasPixels"),
Move the permissions handling into the `BaseViewer` (PR 11789 follow-up) Besides making the permissions-functionality directly available in the viewer-components, these changes are also necessary for the next patch.
2021-12-12 00:23:29 +09:00
enablePermissions: AppOptions.get("enablePermissions"),
Support custom `pageColors` in the thumbnails (PR 14874) Currently, when non-standard `pageColors` are specified, the thumbnails will look inconsistent depending on how they're created. The thumbnails that are created by downsizing the *page* canvases will obviously use the `pageColors` as intended, however the thumbnails which are rendered *directly* will always use the default colors.
2022-05-26 16:45:05 +09:00
pageColors,
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
});
pdfRenderingQueue.setViewer(this.pdfViewer);
pdfLinkService.setViewer(this.pdfViewer);
[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 08:15:18 +09:00
pdfScriptingManager.setViewer(this.pdfViewer);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.sidebar?.thumbnailView) {
this.pdfThumbnailViewer = new PDFThumbnailViewer({
container: appConfig.sidebar.thumbnailView,
renderingQueue: pdfRenderingQueue,
linkService: pdfLinkService,
l10n: this.l10n,
pageColors,
});
pdfRenderingQueue.setThumbnailViewer(this.pdfThumbnailViewer);
}
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
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 21:21:15 +09:00
// The browsing history is only enabled when the viewer is standalone,
// i.e. not when it is embedded in a web page.
if (!this.isViewerEmbedded && !AppOptions.get("disableHistory")) {
this.pdfHistory = new PDFHistory({
linkService: pdfLinkService,
eventBus,
});
pdfLinkService.setHistory(this.pdfHistory);
}
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
if (!this.supportsIntegratedFind && appConfig.findBar) {
Avoid creating a `PDFFindBar` instance, in the Firefox built-in viewer, when not actually necessary This is similar to how `PDFPresentationMode` isn't used when the Fullscreen API isn't supported.
2019-07-21 20:42:03 +09:00
this.findBar = new PDFFindBar(appConfig.findBar, eventBus, this.l10n);
}
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.annotationEditorParams) {
if (annotationEditorMode !== AnnotationEditorType.DISABLE) {
this.annotationEditorParams = new AnnotationEditorParams(
appConfig.annotationEditorParams,
eventBus
);
} else {
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
for (const id of ["editorModeButtons", "editorModeSeparator"]) {
document.getElementById(id)?.classList.add("hidden");
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
}
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
}
}
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.documentProperties) {
this.pdfDocumentProperties = new PDFDocumentProperties(
appConfig.documentProperties,
this.overlayManager,
eventBus,
this.l10n,
/* fileNameLookup = */ () => {
return this._docFilename;
}
);
}
Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing e.g. the viewer components Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
2016-12-08 21:30:21 +09:00
[GeckoView] Don't initalize the cursor-tools, since they're unused The reasons for making this change are: - There's no UI available to toggle the cursor-tools in the GeckoView-specific viewer. - The `HandTool`-implementation basically *simulates* touch scrolling, and is thus unlikely to be helpful/useful anyway. - PR 15831 already changed the relevant call-sites to handle `PDFViewerApplication.pdfCursorTools` being undefined.
2023-02-04 02:13:07 +09:00
// NOTE: The cursor-tools are unlikely to be helpful/useful in GeckoView,
// in particular the `HandTool` which basically simulates touch scrolling.
if (appConfig.secondaryToolbar?.cursorHandToolButton) {
this.pdfCursorTools = new PDFCursorTools({
container,
eventBus,
cursorToolOnLoad: AppOptions.get("cursorToolOnLoad"),
});
}
Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing e.g. the viewer components Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
2016-12-08 21:30:21 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.toolbar) {
this.toolbar = new Toolbar(appConfig.toolbar, eventBus, this.l10n);
}
Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing e.g. the viewer components Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
2016-12-08 21:30:21 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.secondaryToolbar) {
this.secondaryToolbar = new SecondaryToolbar(
appConfig.secondaryToolbar,
eventBus,
this.externalServices
);
}
Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing e.g. the viewer components Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
2016-12-08 21:30:21 +09:00
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
if (
this.supportsFullscreen &&
appConfig.secondaryToolbar?.presentationModeButton
) {
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
this.pdfPresentationMode = new PDFPresentationMode({
container,
pdfViewer: this.pdfViewer,
Enable the `object-shorthand` ESLint rule in `web` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-28 19:02:42 +09:00
eventBus,
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
});
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.passwordOverlay) {
this.passwordPrompt = new PasswordPrompt(
appConfig.passwordOverlay,
this.overlayManager,
this.l10n,
this.isViewerEmbedded
);
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.sidebar?.outlineView) {
this.pdfOutlineViewer = new PDFOutlineViewer({
container: appConfig.sidebar.outlineView,
eventBus,
linkService: pdfLinkService,
downloadManager,
});
}
Revert "Move the `Preferences` initialization/fetching code to the top of `PDFViewerApplication.initialize`, to enable using them when initializing the viewer components" This reverts commit ffb876fdf4b4dbc38273609b9b16b7a341decc02.
2016-09-04 03:27:01 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.sidebar?.attachmentsView) {
this.pdfAttachmentViewer = new PDFAttachmentViewer({
container: appConfig.sidebar.attachmentsView,
eventBus,
downloadManager,
});
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.sidebar?.layersView) {
this.pdfLayerViewer = new PDFLayerViewer({
container: appConfig.sidebar.layersView,
eventBus,
l10n: this.l10n,
});
}
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (appConfig.sidebar) {
this.pdfSidebar = new PDFSidebar({
elements: appConfig.sidebar,
pdfViewer: this.pdfViewer,
pdfThumbnailViewer: this.pdfThumbnailViewer,
eventBus,
l10n: this.l10n,
});
this.pdfSidebar.onToggled = this.forceRendering.bind(this);
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfSidebarResizer = new PDFSidebarResizer(
appConfig.sidebarResizer,
eventBus,
this.l10n
);
}
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
},
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
run(config) {
Moves all document.getElementById lookups into viewer.js
2016-04-22 01:39:11 +09:00
this.initialize(config).then(webViewerInitialized);
Prepare viewer.js for async loading and module separation.
2016-04-02 00:29:44 +09:00
},
Add a `PDFViewerApplication.initializedPromise` property to allow (easier) tracking of when the default viewer has been initialized This complements the existing `PDFViewerApplication.initialized` boolean property, and may be helpful for custom implementations of the default viewer. This will thus provide users of the default viewer an alternative to setting the preference to dispatch events to the DOM (and listen for the "localized" event), since they can instead use: ```javascript document.addEventListener("webviewerloaded", function() { PDFViewerApplication.initializedPromise.then(function() { // The viewer has now been initialized. }) }); ``` Note that in order to avoid manually tracking the initialization state *twice*, this implementation purposely uses the `PromiseCapability` functionality to handle both `PDFViewerApplication.initialized` and `PDFViewerApplication.initializedPromise` internally.
2020-02-17 20:49:56 +09:00
get initialized() {
return this._initializedCapability.settled;
},
get initializedPromise() {
return this._initializedCapability.promise;
},
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
zoomIn(steps, scaleFactor) {
Ensure that `PDFViewerApplication.{zoomIn, zoomOut}` won't run when PresentationMode is active (PR 10652 follow-up) Similar to the `zoomReset` method we need to ensure that this code won't run for zoom events originating within the browser UI itself, since checks in e.g. the `keydown` event handler won't help in that case.
2019-07-11 22:35:05 +09:00
if (this.pdfViewer.isInPresentationMode) {
return;
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
this.pdfViewer.increaseScale({
Improve name consistency in the viewer (PR 15812 follow-up) This tweaks a few name that originated in PR 15812, to improve overall consistency: - Use the `drawingDelay` parameter-name in all methods that accept a delay. - Use the `postponeDrawing` variable-name in all relevant methods.
2022-12-28 21:26:01 +09:00
drawingDelay: AppOptions.get("defaultZoomDelay"),
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
steps,
scaleFactor,
Only redraw after zooming is finished (bug 1661253) Right now, the visible pages are redrawn for each scale change. Consequently, zooming with mouse wheel or in pinching can be pretty janky (even on a desktop machine but with a hdpi screen). So the main idea in this patch is to draw the visible pages only once zooming is finished.
2022-12-12 22:24:27 +09:00
});
Zooming control
2011-09-03 10:16:52 +09:00
},
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
zoomOut(steps, scaleFactor) {
Ensure that `PDFViewerApplication.{zoomIn, zoomOut}` won't run when PresentationMode is active (PR 10652 follow-up) Similar to the `zoomReset` method we need to ensure that this code won't run for zoom events originating within the browser UI itself, since checks in e.g. the `keydown` event handler won't help in that case.
2019-07-11 22:35:05 +09:00
if (this.pdfViewer.isInPresentationMode) {
return;
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
this.pdfViewer.decreaseScale({
Improve name consistency in the viewer (PR 15812 follow-up) This tweaks a few name that originated in PR 15812, to improve overall consistency: - Use the `drawingDelay` parameter-name in all methods that accept a delay. - Use the `postponeDrawing` variable-name in all relevant methods.
2022-12-28 21:26:01 +09:00
drawingDelay: AppOptions.get("defaultZoomDelay"),
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
steps,
scaleFactor,
Only redraw after zooming is finished (bug 1661253) Right now, the visible pages are redrawn for each scale change. Consequently, zooming with mouse wheel or in pinching can be pretty janky (even on a desktop machine but with a hdpi screen). So the main idea in this patch is to draw the visible pages only once zooming is finished.
2022-12-12 22:24:27 +09:00
});
Zooming control
2011-09-03 10:16:52 +09:00
},
[Firefox] Re-factor the 'zoomreset' message handling in the viewer (PR 10652 follow-up) Given that this special-case only matters for the Firefox PDF viewer, it's probably better to just move it into `firefoxcom.js` instead to reduce unnecessary confusion.
2019-07-17 18:59:56 +09:00
zoomReset() {
Prepare the `MOZCENTRAL` viewer for receiving zoom events from the browser UI (bug 786674, bug 1177385) This lays the necessary foundation for handling zoom events originating within the browser itself, rather than in the viewer. Please note that this will also require a follow-up patch to `mozilla-central`, such that the viewer is actually notified when zooming occurs.
2019-03-19 18:45:27 +09:00
if (this.pdfViewer.isInPresentationMode) {
return;
}
this.pdfViewer.currentScaleValue = DEFAULT_SCALE_VALUE;
},
Moves viewer code into PDFViewer and some code from PageView.
2014-09-13 11:27:45 +09:00
get pagesCount() {
Log an error when the value passed to `set currentPageNumber` is out of bounds (PR 7502 followup) With PR 7502 we no longer dispatch an event when the `val` is out of bounds, so to better communicate why nothing happens this patch logs an error in that case (similar to the logging of errors when trying to set an invalid scale). The way that the default viewer is currently implemented, means that e.g. keyboard short-cuts could trigger the new error. Hence this patch also adds the necessary validation code, both to `app.js` and `pdf_link_service.js` to prevent unnecessary errors.
2016-08-07 20:10:50 +09:00
return this.pdfDocument ? this.pdfDocument.numPages : 0;
Moves viewer code into PDFViewer and some code from PageView.
2014-09-13 11:27:45 +09:00
},
Add "bookmark" icon; and fixing scale/ current page number issues
2011-10-15 11:05:57 +09:00
Log an error when the value passed to `set currentPageNumber` is out of bounds (PR 7502 followup) With PR 7502 we no longer dispatch an event when the `val` is out of bounds, so to better communicate why nothing happens this patch logs an error in that case (similar to the logging of errors when trying to set an invalid scale). The way that the default viewer is currently implemented, means that e.g. keyboard short-cuts could trigger the new error. Hence this patch also adds the necessary validation code, both to `app.js` and `pdf_link_service.js` to prevent unnecessary errors.
2016-08-07 20:10:50 +09:00
get page() {
return this.pdfViewer.currentPageNumber;
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
},
Enable the ESLint `grouped-accessor-pairs` rule This rule complements the existing `accessor-pairs` nicely, and ensures that a getter/setter pair is always consistently ordered. Please find additional details about this rule at https://eslint.org/docs/rules/grouped-accessor-pairs
2020-05-07 18:43:19 +09:00
set page(val) {
this.pdfViewer.currentPageNumber = val;
},
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
get supportsPrinting() {
Simplify PDFViewerApplication::supportsPrinting (follow-up of #15894)
2023-01-11 20:33:33 +09:00
return PDFPrintServiceFactory.instance.supportsPrinting;
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
},
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
get supportsFullscreen() {
Only support the standard, unprefixed, Fullscreen API in the default viewer At this point in time, after recent rounds of clean-up, the `webkit`-prefixed Fullscreen API is the only remaining *browser-specific* compatibility hack in the `web/`-folder JavaScript code. The standard, and thus unprefixed, Fullscreen API has been supported for *over three years* in both Mozilla Firefox and Google Chrome. [According to MDN](https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API#browser_compatibility), the unprefixed Fullscreen API has been available since: - Mozilla Firefox 64, released on 2018-12-11; see https://wiki.mozilla.org/Release_Management/Calendar#Past_branch_dates - Google Chrome 71, released on 2018-12-04; see https://en.wikipedia.org/wiki/Google_Chrome_version_history Hence *only* Safari now requires using a prefixed Fullscreen API, and it's thus (significantly) lagging behind other browsers in this regard. Considering that the default viewer is written *specifically* to be the UI for the Firefox PDF Viewer, and that we ask users to not just use it as-is[1], I think that we should only support the standard Fullscreen API now. Furthermore, note also that the FAQ already lists Safari as "Mostly" supported; see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support --- [1] Note e.g. http://mozilla.github.io/pdf.js/getting_started/#introduction > The viewer is built on the display layer and is the UI for PDF viewer in Firefox and the other browser extensions within the project. It can be a good starting point for building your own viewer. *However, we do ask if you plan to embed the viewer in your own site, that it not just be an unmodified version. Please re-skin it or build upon it.*
2022-02-25 23:36:45 +09:00
return shadow(this, "supportsFullscreen", document.fullscreenEnabled);
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
},
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
get supportsPinchToZoom() {
return this.externalServices.supportsPinchToZoom;
},
Add support for firefox integrated find.
2012-10-06 05:59:13 +09:00
get supportsIntegratedFind() {
Refactors firefoxcom dependency on app and l10n.
2016-04-14 06:21:05 +09:00
return this.externalServices.supportsIntegratedFind;
Add support for firefox integrated find.
2012-10-06 05:59:13 +09:00
},
Detecting if web fonts are disable in Firefox.
2012-12-01 07:59:51 +09:00
get supportsDocumentFonts() {
Refactors firefoxcom dependency on app and l10n.
2016-04-14 06:21:05 +09:00
return this.externalServices.supportsDocumentFonts;
Detecting if web fonts are disable in Firefox.
2012-12-01 07:59:51 +09:00
},
Fix the positioning of the progressive loadingBar
2013-07-19 01:28:59 +09:00
get loadingBar() {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
const barElement = document.getElementById("loadingBar");
const bar = barElement ? new ProgressBar(barElement) : null;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return shadow(this, "loadingBar", bar);
Fix the positioning of the progressive loadingBar
2013-07-19 01:28:59 +09:00
},
[Firefox] Handle the user modifying the "mousewheel.with_meta.action" and "mousewheel.with_control.action" prefs (bug 1170063) Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1170063. The bug only mentions the <kbd>Meta</kbd> key, but given that a similar situation can occur for <kbd>Ctrl</kbd>, it seemed reasonable to also handle that case in the same patch. The only possible caveat with the patch is that because of the use of `shadow`, things won't work perfectly if either of the prefs are changed *while* the viewer is active. In this case a reload is required in order for it to work correctly, but given that the issue this patch fixes should be quite rare anyway, that seems OK.
2015-06-02 20:17:02 +09:00
get supportedMouseWheelZoomModifierKeys() {
Refactors firefoxcom dependency on app and l10n.
2016-04-14 06:21:05 +09:00
return this.externalServices.supportedMouseWheelZoomModifierKeys;
[Firefox] Handle the user modifying the "mousewheel.with_meta.action" and "mousewheel.with_control.action" prefs (bug 1170063) Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1170063. The bug only mentions the <kbd>Meta</kbd> key, but given that a similar situation can occur for <kbd>Ctrl</kbd>, it seemed reasonable to also handle that case in the same patch. The only possible caveat with the patch is that because of the use of `shadow`, things won't work perfectly if either of the prefs are changed *while* the viewer is active. In this case a reload is required in order for it to work correctly, but given that the issue this patch fixes should be quite rare anyway, that seems OK.
2015-06-02 20:17:02 +09:00
},
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
initPassiveLoading() {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
typeof PDFJSDev === "undefined" ||
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
!PDFJSDev.test("MOZCENTRAL || CHROME")
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
throw new Error("Not implemented: initPassiveLoading");
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
this.externalServices.initPassiveLoading({
Remove unused parameters from the `onOpenWithTransport` method in `PDFViewerApplication.initPassiveLoading` The only parameter that we actually need here is the `PDFDataRangeTransport`-instance, since the others are not necessary. - The `url` parameter, as passed to the `getDocument` function in the API, is simply being ignored; see https://github.com/mozilla/pdf.js/blob/2d87a2eb1ccce55b8099bf2b8fcc7ed51bd6fbc9/src/display/api.js#L447-L458 - The `length` parameter, as passed to the `getDocument` function in the API, is always being overwritten; see https://github.com/mozilla/pdf.js/blob/2d87a2eb1ccce55b8099bf2b8fcc7ed51bd6fbc9/src/display/api.js#L519-L525
2023-02-01 05:34:42 +09:00
onOpenWithTransport: range => {
this.open({ range });
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
},
[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-24 21:02:58 +09:00
onOpenWithData: (data, contentDispositionFilename) => {
if (isPdfFile(contentDispositionFilename)) {
this._contentDispositionFilename = contentDispositionFilename;
}
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
this.open({ data });
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
},
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 22:06:32 +09:00
onOpenWithURL: (url, length, originalUrl) => {
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
this.open({ url, length, originalUrl });
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
},
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 22:06:32 +09:00
onError: err => {
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-02-22 20:43:16 +09:00
this.l10n.get("loading_error").then(msg => {
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-10 23:57:58 +09:00
this._documentError(msg, err);
});
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
},
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 22:06:32 +09:00
onProgress: (loaded, total) => {
this.progress(loaded / total);
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
},
});
Implements loading PDF data by extension/chrome
2012-08-01 02:21:07 +09:00
},
[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-12 19:34:58 +09:00
setTitleUsingUrl(url = "", downloadUrl = null) {
Implements loading PDF data by extension/chrome
2012-08-01 02:21:07 +09:00
this.url = url;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.baseUrl = url.split("#")[0];
[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-12 19:34:58 +09:00
if (downloadUrl) {
this._downloadUrl =
downloadUrl === url ? this.baseUrl : downloadUrl.split("#")[0];
}
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
if (isDataScheme(url)) {
this._hideViewBookmark();
}
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-16 19:56:31 +09:00
let title = getPdfFilenameFromUrl(url, "");
Set title using logic similar as download name The download method (and the PDF document properties) detect the file name using `getPDFFileNameFromURL`. The title ought to also display the PDF filename if available.
2017-02-06 08:46:12 +09:00
if (!title) {
try {
Convert a number of `import * as pdfjsLib from 'pdfjs-web/pdfjs';` cases to only specify the necessary imports Rather than always importing everything from the `web/pdfjs.js`, similar to all other imports we can just choose what we actually need.
2017-03-28 17:15:02 +09:00
title = decodeURIComponent(getFilenameFromUrl(url)) || url;
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
} catch (ex) {
Set title using logic similar as download name The download method (and the PDF document properties) detect the file name using `getPDFFileNameFromURL`. The title ought to also display the PDF filename if available.
2017-02-06 08:46:12 +09:00
// decodeURIComponent may throw URIError,
// fall back to using the unprocessed url in that case
title = url;
}
Gracefully fail if the URL filename cannot be decoded.
2012-08-27 08:49:07 +09:00
}
Set title using logic similar as download name The download method (and the PDF document properties) detect the file name using `getPDFFileNameFromURL`. The title ought to also display the PDF filename if available.
2017-02-06 08:46:12 +09:00
this.setTitle(title);
Implements loading PDF data by extension/chrome
2012-08-01 02:21:07 +09:00
},
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
setTitle(title = this._title) {
this._title = title;
Embedded PDF viewers should not be changing their parent page's title.
2015-03-06 12:36:08 +09:00
if (this.isViewerEmbedded) {
// Embedded PDF viewers should not be changing their parent page's title.
return;
}
Disable the editing-indicator, in the document title, during printing (bug 1790552, PR 15351 follow-up)
2022-09-13 17:57:10 +09:00
const editorIndicator =
this._hasAnnotationEditors && !this.pdfRenderingQueue.printing;
document.title = `${editorIndicator ? "* " : ""}${title}`;
Add close button and title bar for b2g.
2012-11-29 04:02:56 +09:00
},
Add a new helper method, on `PDFViewerApplication`, to determine the document filename Currently this code is duplicated no less than three times in the `web/app.js` file, and by introducing a helper method we can avoid unnecessary repetition.
2021-01-02 07:03:18 +09:00
get _docFilename() {
// Use `this.url` instead of `this.baseUrl` to perform filename detection
// based on the reference fragment as ultimate fallback if needed.
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-16 19:56:31 +09:00
return this._contentDispositionFilename || getPdfFilenameFromUrl(this.url);
Add a new helper method, on `PDFViewerApplication`, to determine the document filename Currently this code is duplicated no less than three times in the `web/app.js` file, and by introducing a helper method we can avoid unnecessary repetition.
2021-01-02 07:03:18 +09:00
},
[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-12 19:34:58 +09:00
/**
* @private
*/
_hideViewBookmark() {
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
const { secondaryToolbar } = this.appConfig;
[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-12 19:34:58 +09:00
// URL does not reflect proper document location - hiding some buttons.
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
secondaryToolbar?.viewBookmarkButton.classList.add("hidden");
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
// Avoid displaying multiple consecutive separators in the secondaryToolbar.
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
if (secondaryToolbar?.presentationModeButton.classList.contains("hidden")) {
document.getElementById("viewBookmarkSeparator")?.classList.add("hidden");
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
}
[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-12 19:34:58 +09:00
},
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
/**
* Closes opened PDF document.
* @returns {Promise} - Returns the promise, which is resolved when all
* destruction is completed.
*/
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
async close() {
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-08 03:53:43 +09:00
this._unblockDocumentLoadEvent();
[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-12 19:34:58 +09:00
this._hideViewBookmark();
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-08 03:53:43 +09:00
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
if (!this.pdfLoadingTask) {
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
return;
}
if (
(typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) &&
this.pdfDocument?.annotationStorage.size > 0 &&
this._annotationStorageModified
) {
try {
// Trigger saving, to prevent data loss in forms; see issue 12257.
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
await this.save();
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
} catch (reason) {
// Ignoring errors, to ensure that document closing won't break.
}
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
}
Move destroying of the scripting-instance from `PDFViewerApplication.close` and into its own helper method Since the `close` method has become quite large, this small re-factoring shouldn't hurt (and may also be useful with future changes to the `_initializeJavaScript` method).
2020-12-08 01:54:44 +09:00
const promises = [];
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
Move destroying of the scripting-instance from `PDFViewerApplication.close` and into its own helper method Since the `close` method has become quite large, this small re-factoring shouldn't hurt (and may also be useful with future changes to the `_initializeJavaScript` method).
2020-12-08 01:54:44 +09:00
promises.push(this.pdfLoadingTask.destroy());
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
this.pdfLoadingTask = null;
if (this.pdfDocument) {
this.pdfDocument = null;
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfThumbnailViewer?.setDocument(null);
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
this.pdfViewer.setDocument(null);
Update `{PDFLinkService, PDFDocumentProperties}.setDocument` to make the "url" parameter optional This way the resetting of `PDFLinkService`/`PDFDocumentProperties` instances, as is done in `PDFViewerApplication.close`, only requires passing in *one* `null` argument instead of two.
2018-09-30 19:11:27 +09:00
this.pdfLinkService.setDocument(null);
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfDocumentProperties?.setDocument(null);
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
}
Reset the `IPDFLinkService.externalLinkEnabled` property on document closing Given that this property is only used with password protected documents, and is consequently document-specific rather than viewer-specific, ensure that `IPDFLinkService.externalLinkEnabled` is actually being reset by `PDFViewerApplication.close`. To make things less confusing/inconsistent, remove the *undocumented* `externalLinkEnabled` property from the `PDFLinkService` constructor and force it to always be manually set when needed.
2021-06-23 21:00:54 +09:00
this.pdfLinkService.externalLinkEnabled = true;
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
this.store = null;
this.isInitialViewSet = false;
Reset `pageRotation` and `downloadComplete` in `PDFViewerApplication.close` Currently, these properties are reset in what appears to be somewhat arbitrary locations (within the `load` and `open` methods respectively). The explanation is probably that both of these properties predates the existence of any centralized clean-up code in the viewer. Hence I think that it makes sense to move the resetting of these properties to the `close` method, since that improves the overview of what's actually cleaned-up/reset when changing documents in the viewer.
2017-06-17 20:14:36 +09:00
this.downloadComplete = false;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.url = "";
this.baseUrl = "";
[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-12 19:34:58 +09:00
this._downloadUrl = "";
Dispatch a `metadataloaded` event once the `PDFViewerApplication._initializeMetadata` method is done This will be useful in the following patch, and note that there's also an old issue (see 5765) which asked for such an event. However, given that the use-case wasn't *clearly* specified, and that we didn't have an internal use for it at the time it wasn't implemented. Also, ensure that all of the metadata-related properties are actually reset when the document is closed.
2020-12-06 20:30:33 +09:00
this.documentInfo = null;
this.metadata = null;
Tweak the "filesize" handling in `PDFViewerApplication._initializeJavaScript` Another possible option here could be to use the `contentLength`, when it exists, and then using e.g. a custom event to always update the "filesize" in the sandbox "after the fact" with the result of the `getDownloadInfo`-call.
2020-12-06 21:00:34 +09:00
this._contentDispositionFilename = null;
this._contentLength = null;
Add support for saving forms
2020-08-04 02:44:04 +09:00
this._saveInProgress = false;
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
this._hasAnnotationEditors = false;
Move cancelling of idleCallbacks from `PDFViewerApplication.close` and into its own helper method Since the `close` method has become quite large, this small re-factoring shouldn't hurt.
2020-12-08 01:21:49 +09:00
[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 08:15:18 +09:00
promises.push(this.pdfScriptingManager.destroyPromise);
Actually remove a `scripting`-instance, and its global events, upon document closing I was actually quite surprised to find that, despite the various `scripting`-getters implementing `destroySandbox` methods, there were no attempts at actually cleaning-up either the "sandbox" or removing the globally registered event listeners.
2020-12-06 21:57:24 +09:00
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
this.setTitle();
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfSidebar?.reset();
this.pdfOutlineViewer?.reset();
this.pdfAttachmentViewer?.reset();
this.pdfLayerViewer?.reset();
Refactor how `PDFOutlineView`/`PDFAttachmentView` is initialized in viewer.js, rename the classes, and refactor their `render` methods Changes `PDFOutlineView`/`PDFAttachmentView` to be initialized once, since we're always creating them, and refactor their `render` methods to instead pass in the `outline`/`attachments`. For consistency with other "classes", the `PDFOutlineView`/`PDFAttachmentView` are renamed to `PDFOutlineViewer`/`PDFAttachmentViewer`. Also, make sure that the outline/attachments are reset when the document is closed. Currently we keep the old ones around until the `getOutline`/`getAttachments` API calls are resolved for a new document.
2016-02-21 21:36:24 +09:00
Use optional chaining even more in the `web/app.js` file
2021-08-28 00:29:00 +09:00
this.pdfHistory?.reset();
this.findBar?.reset();
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.toolbar?.reset();
this.secondaryToolbar?.reset();
Convert `web/debugger.js` to a *basic* module The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures. Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer. Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally. According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations. --- [1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
this._PDFBug?.cleanup();
Ensure that `PDFFindController_reset` actually resets *all* state (issue 7034) To reduce code duplication, the initialization code now uses the `reset` method. Also, this patch moves `charactersToNormalize` out of `PDFFindController`, since it seemed better suited to be a "constant".
2016-02-27 02:06:59 +09:00
Ensure that `PDFViewerApplication.close` has a *consistent* return value
2021-01-12 22:29:15 +09:00
await Promise.all(promises);
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
},
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
/**
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
* Opens a new PDF document.
* @param {Object} args - Accepts any/all of the properties from
* {@link DocumentInitParameters}, and also a `originalUrl` string.
* @returns {Promise} - Promise that is resolved when the document is opened.
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
*/
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
async open(args) {
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
let deprecatedArgs = false;
if (typeof args === "string") {
args = { url: args }; // URL
deprecatedArgs = true;
} else if (args?.byteLength) {
args = { data: args }; // ArrayBuffer
deprecatedArgs = true;
}
if (deprecatedArgs) {
console.error(
"The `PDFViewerApplication.open` signature was updated, please use an object instead."
);
}
}
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
if (this.pdfLoadingTask) {
// We need to destroy already opened document.
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
await this.close();
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
}
Refactor how the default viewer handles the worker options, by making use of `AppOptions` instead of the global `PDFJS` object
2018-02-17 23:33:57 +09:00
// Set the necessary global worker parameters, using the available options.
Remove a couple of manual loops in the `PDFViewerApplication.open` method Some of the code in this method is *very* old, and we could thus modernize it a little bit by removing a couple of the loops used to build the `getDocument` argument.
2023-02-01 19:13:28 +09:00
const workerParams = AppOptions.getAll(OptionKind.WORKER);
Object.assign(GlobalWorkerOptions, workerParams);
Cleaning up the viewer and pdfbug; fixes repeats in Stepper
2014-03-27 05:18:53 +09:00
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
if (
(typeof PDFJSDev === "undefined" || !PDFJSDev.test("MOZCENTRAL")) &&
args.url
) {
// The Firefox built-in viewer always calls `setTitleUsingUrl`, before
// `initPassiveLoading`, and it never provides an `originalUrl` here.
Re-factor the parameter parsing/validation in `getDocument` This is very old code, where we loop through the user-provided options and build an internal parameter object. To prevent errors we also need to ensure that the parameters are correct/valid, which is especially important for the ones that are sent to the worker-thread such that structured cloning won't fail.[1] Over the years this has led to more and more code being added in `getDocument` to validate the user-provided options, and at this point *most* of them have at least basic validation. However the way that this is implemented feels slightly backwards, since we first build the internal parameter object and only *afterwards* validate those parameters.[2] Hence this patch changes the `getDocument` function to instead check/validate the supported options upfront, and then *explicitly* build the internal parameter object with only the needed properties. --- [1] Note the supported types at https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types [2] The internal parameter object may also, because of the loop, end up with lots of unnecessary properties since anything that the user provides is being copied.
2023-01-29 20:21:21 +09:00
this.setTitleUsingUrl(
args.originalUrl || args.url,
/* downloadUrl = */ args.url
);
Support password and add the relevant l10n strings
2012-05-15 03:45:07 +09:00
}
Remove a couple of manual loops in the `PDFViewerApplication.open` method Some of the code in this method is *very* old, and we could thus modernize it a little bit by removing a couple of the loops used to build the `getDocument` argument.
2023-02-01 19:13:28 +09:00
// Set the necessary API parameters, using all the available options.
const apiParams = AppOptions.getAll(OptionKind.API);
[api-minor] Add an option to set the max canvas area
2023-03-07 01:16:43 +09:00
const params = {
canvasMaxAreaInBytes: this.externalServices.canvasMaxAreaInBytes,
...apiParams,
...args,
};
Add the `docBaseUrl` API parameter to `AppOptions` in the viewer This unfortunately required a bit of special handling, to correctly deal with the various extension builds.
2019-07-20 20:39:34 +09:00
Remove a couple of manual loops in the `PDFViewerApplication.open` method Some of the code in this method is *very* old, and we could thus modernize it a little bit by removing a couple of the loops used to build the `getDocument` argument.
2023-02-01 19:13:28 +09:00
if (typeof PDFJSDev === "undefined" || !PDFJSDev.test("PRODUCTION")) {
params.docBaseUrl ||= document.URL.split("#")[0];
} else if (PDFJSDev.test("MOZCENTRAL || CHROME")) {
params.docBaseUrl ||= this.baseUrl;
Refactor how the default viewer handles the worker options, by making use of `AppOptions` instead of the global `PDFJS` object
2018-02-17 23:33:57 +09:00
}
Remove a couple of manual loops in the `PDFViewerApplication.open` method Some of the code in this method is *very* old, and we could thus modernize it a little bit by removing a couple of the loops used to build the `getDocument` argument.
2023-02-01 19:13:28 +09:00
const loadingTask = getDocument(params);
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
this.pdfLoadingTask = loadingTask;
Adds deprecation warning for the API calls.
2015-10-21 22:54:31 +09:00
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
loadingTask.onPassword = (updateCallback, reason) => {
Unblock the load event when the pdf has a password (bug 1801341)
2022-11-23 01:48:53 +09:00
if (this.isViewerEmbedded) {
// The load event can't be triggered until the password is entered, so
// if the viewer is in an iframe and its visibility depends on the
// onload callback then the viewer never shows (bug 1801341).
this._unblockDocumentLoadEvent();
}
Add a way to disable external links.
2019-08-21 06:43:24 +09:00
this.pdfLinkService.externalLinkEnabled = false;
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
this.passwordPrompt.setUpdateCallback(updateCallback, reason);
this.passwordPrompt.open();
Fixes password for range request loading
2013-05-10 07:35:23 +09:00
};
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
loadingTask.onProgress = ({ loaded, total }) => {
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
this.progress(loaded / total);
Adds deprecation warning for the API calls.
2015-10-21 22:54:31 +09:00
};
Use A+ spec compatible promises.
2013-06-06 04:28:31 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return loadingTask.promise.then(
pdfDocument => {
this.load(pdfDocument);
},
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
reason => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (loadingTask !== this.pdfLoadingTask) {
return undefined; // Ignore errors for previously opened PDF files.
}
Don't display error messages, in the default viewer, for PDF files other than the current one We've never attempted to limit the errors displayed in the default viewer to the current PDF file, but that's not really been a problem before. However after PR 7926, it's now possible to get password related error messages for *previously* opened PDF files in the default viewer. **STR:** 1. Open a password protected PDF file, e.g. `issue6010_1.pdf` from the test-suite. 2. Cancel the password prompt. 3. Open any new PDF file in the viewer. **AR:** The error UI is displayed, with a `No password given` message. **ER:** No error displayed, since it's only relevent for a now closed PDF file. This is obviously a minor issue, caused by us now rejecting the still pending `pdfLoadingTask` during the `PDFViewerApplication.close` call, but I don't think that it (generally) makes sense to show errors if they're not relevant to the *currently* displayed PDF file.
2017-11-23 21:44:26 +09:00
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-10 23:57:58 +09:00
let key = "loading_error";
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
if (reason instanceof InvalidPDFException) {
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-10 23:57:58 +09:00
key = "invalid_file_error";
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
} else if (reason instanceof MissingPDFException) {
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-10 23:57:58 +09:00
key = "missing_file_error";
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
} else if (reason instanceof UnexpectedResponseException) {
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-10 23:57:58 +09:00
key = "unexpected_response_error";
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
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-02-22 20:43:16 +09:00
return this.l10n.get(key).then(msg => {
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
this._documentError(msg, { message: reason?.message });
throw reason;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
}
);
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
},
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
/**
* @private
*/
_ensureDownloadComplete() {
if (this.pdfDocument && this.downloadComplete) {
return;
Improve download button and behaviour Fix download button for top frames and sub frames When PDF.js is the top frame, and the PDF URL is identical to the top URL, download would fail. Fixed by adding a ? or & in these cases. When PDF.js is embedded in a frame from a different origin, download would fail because window.open(url, '_parent') is ignored. Fixed by using a.click() when available. a.click() works in Chrome 25, Firefox 19, Opera 12.00 and IE 8. Safari 5.1 does not support a.click() Use a.download if available + documentation
2013-03-25 02:25:57 +09:00
}
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
throw new Error("PDF document not downloaded.");
},
Refactoring download button logic
2013-07-13 03:14:13 +09:00
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
async download() {
[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-12 19:34:58 +09:00
const url = this._downloadUrl,
Add a new helper method, on `PDFViewerApplication`, to determine the document filename Currently this code is duplicated no less than three times in the `web/app.js` file, and by introducing a helper method we can avoid unnecessary repetition.
2021-01-02 07:03:18 +09:00
filename = this._docFilename;
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
try {
this._ensureDownloadComplete();
Refactoring download button logic
2013-07-13 03:14:13 +09:00
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
const data = await this.pdfDocument.getData();
const blob = new Blob([data], { type: "application/pdf" });
Fix download button waiting if document has started but not completed downloading
2014-03-14 12:23:47 +09:00
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
await this.downloadManager.download(blob, url, filename);
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
} catch (reason) {
// When the PDF document isn't ready, or the PDF file is still
// downloading, simply download using the URL.
await this.downloadManager.downloadUrl(url, filename);
}
Make the 'download' button behavior more robust
2011-10-19 13:29:14 +09:00
},
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
async save() {
Add support for saving forms
2020-08-04 02:44:04 +09:00
if (this._saveInProgress) {
return;
}
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
this._saveInProgress = true;
await this.pdfScriptingManager.dispatchWillSave();
Add support for saving forms
2020-08-04 02:44:04 +09:00
[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-12 19:34:58 +09:00
const url = this._downloadUrl,
Add a new helper method, on `PDFViewerApplication`, to determine the document filename Currently this code is duplicated no less than three times in the `web/app.js` file, and by introducing a helper method we can avoid unnecessary repetition.
2021-01-02 07:03:18 +09:00
filename = this._docFilename;
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
try {
this._ensureDownloadComplete();
Add support for saving forms
2020-08-04 02:44:04 +09:00
[api-minor] Remove the manual passing of an `AnnotationStorage`-instance when calling various API-method Note how we purposely don't expose the `AnnotationStorage`-class directly in the official API (see `src/pdf.js`), since trying to use *multiple* ones simultaneously doesn't really make sense (e.g. in the viewer). Instead we lazily initialize, and cache, just *one* instance via `PDFDocumentProxy.annotationStorage` which should thus be available internally in the API itself without having to be manually passed to various methods. To support these changes, the `AnnotationStorage`-instance initialization is moved into the `WorkerTransport`-class to allow both `PDFDocumentProxy` and `PDFPageProxy` to access it. This patch implements the following simplifications: - Remove the `annotationStorage`-parameter from `PDFDocumentProxy.saveDocument`, since it's already available internally. Furthermore, while it's currently possible to call that method without an `AnnotationStorage`-instance, that really does *not* make any sense at all. In this case you're effectively reducing `PDFDocumentProxy.saveDocument` to a "regular" `PDFDocumentProxy.getData` call, but with *a lot* more overhead, which was obviously not the intention of the `PDFDocumentProxy.saveDocument`-method. - Try to discourage third-party users from calling `PDFDocumentProxy.saveDocument` unconditionally, as a replacement for `PDFDocumentProxy.getData` (note the previous point). - Replace the `annotationStorage`-parameter, in `PDFPageProxy.render`, with a boolean `includeAnnotationStorage`-parameter which simply indicates if the (internally available) `AnnotationStorage`-instance should be used during rendering (e.g. for printing). - By removing the need to *manually* provide `annotationStorage`-parameters to various API-methods, using the API should become simpler (e.g. for third-parties) since you no longer need to worry about manually fetching and passing around this data.
2021-04-04 23:49:06 +09:00
const data = await this.pdfDocument.saveDocument();
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
const blob = new Blob([data], { type: "application/pdf" });
JS - Collect and execute actions at doc and pages level * the goal is to execute actions like Open or OpenAction * can be tested with issue6106.pdf (auto-print) * once #12701 is merged, we can add page actions
2020-12-08 03:22:14 +09:00
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
await this.downloadManager.download(blob, url, filename);
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
} catch (reason) {
// When the PDF document isn't ready, or the PDF file is still
// downloading, simply fallback to a "regular" download.
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-24 01:18:55 +09:00
console.error(`Error when saving the document: ${reason.message}`);
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
await this.download();
Re-factor the `download`/`save`-methods, on `PDFViewerApplication`, to make full use of async/await In the next patch we'll need to be able to actually wait for saving to complete, hence it's necessary to slightly re-factor the `save`-method. As part of these changes, we can reduce some duplication in the `save`-method and slightly improve the overall code. For consistency, the `download`-method is updated similarily to improve the code (this functionality is *very* old, even pre-dating the introduction of Promises in the code-base).
2021-04-03 22:33:14 +09:00
} finally {
await this.pdfScriptingManager.dispatchDidSave();
this._saveInProgress = false;
}
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
if (this._hasAnnotationEditors) {
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
this.externalServices.reportTelemetry({
type: "editing",
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
data: { type: "save" },
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
});
}
Add support for saving forms
2020-08-04 02:44:04 +09:00
},
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
downloadOrSave() {
Move the functionality of the `webViewerDownloadOrSave` function into a new `PDFViewerApplication` method instead Given that this relies on accessing properties on the `PDFDocumentProxy`-instance, it seems more appropriate for this code to live in `PDFViewerApplication`.
2020-12-19 20:38:10 +09:00
if (this.pdfDocument?.annotationStorage.size > 0) {
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
this.save();
Move the functionality of the `webViewerDownloadOrSave` function into a new `PDFViewerApplication` method instead Given that this relies on accessing properties on the `PDFDocumentProxy`-instance, it seems more appropriate for this code to live in `PDFViewerApplication`.
2020-12-19 20:38:10 +09:00
} else {
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
this.download();
Move the functionality of the `webViewerDownloadOrSave` function into a new `PDFViewerApplication` method instead Given that this relies on accessing properties on the `PDFDocumentProxy`-instance, it seems more appropriate for this code to live in `PDFViewerApplication`.
2020-12-19 20:38:10 +09:00
}
},
Display error messages on more problems.
2011-11-30 04:28:05 +09:00
/**
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
* Report the error; used for errors affecting loading and/or parsing of
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-08 03:53:43 +09:00
* the entire PDF document.
*/
_documentError(message, moreInfo = null) {
this._unblockDocumentLoadEvent();
this._otherError(message, moreInfo);
Dispatch a "documenterror" event in `PDFViewerApplication._documentError` (issue 14451) *Please note:* This is a tentative patch, since I don't know if this is deemed important enough to fix. The new event could be seen as a *supplement* to the existing "documentinit" and "documentloaded" events, but for the case when a PDF document fails to load. To make the "documenterror" event generally useful, it'll include both the localized error message as well as the original reason for the error (when that exists).
2022-01-15 19:14:29 +09:00
this.eventBus.dispatch("documenterror", {
source: this,
message,
reason: moreInfo?.message ?? null,
});
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-08 03:53:43 +09:00
},
/**
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
* Report the error; used for errors affecting e.g. only a single page.
Consistently use square brackets for optional parameters in JSDoc comments Square brackets are recommended to indicate optional parameters. Using them helps for automatically generating correct documentation.
2019-10-12 23:30:32 +09:00
* @param {string} message - A message that is human readable.
* @param {Object} [moreInfo] - Further information about the error that is
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
* more technical. Should have a 'message' and
Consistently use square brackets for optional parameters in JSDoc comments Square brackets are recommended to indicate optional parameters. Using them helps for automatically generating correct documentation.
2019-10-12 23:30:32 +09:00
* optionally a 'stack' property.
Display error messages on more problems.
2011-11-30 04:28:05 +09:00
*/
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-08 03:53:43 +09:00
_otherError(message, moreInfo = null) {
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
const moreInfoText = [`PDF.js v${version || "?"} (build: ${build || "?"})`];
Add new severity log info(). Change severity of some log messages. Trigger fallback on errors and warnings for extension.
2012-05-15 09:19:09 +09:00
if (moreInfo) {
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
moreInfoText.push(`Message: ${moreInfo.message}`);
Add new severity log info(). Change severity of some log messages. Trigger fallback on errors and warnings for extension.
2012-05-15 09:19:09 +09:00
if (moreInfo.stack) {
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
moreInfoText.push(`Stack: ${moreInfo.stack}`);
Add new severity log info(). Change severity of some log messages. Trigger fallback on errors and warnings for extension.
2012-05-15 09:19:09 +09:00
} else {
if (moreInfo.filename) {
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
moreInfoText.push(`File: ${moreInfo.filename}`);
Add new severity log info(). Change severity of some log messages. Trigger fallback on errors and warnings for extension.
2012-05-15 09:19:09 +09:00
}
if (moreInfo.lineNumber) {
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
moreInfoText.push(`Line: ${moreInfo.lineNumber}`);
Add new severity log info(). Change severity of some log messages. Trigger fallback on errors and warnings for extension.
2012-05-15 09:19:09 +09:00
}
}
}
Adds support of the indeterminate loading progress
2012-08-23 00:48:56 +09:00
Stop localizing error *details* in the viewer (PR 15533 follow-up) While it can't hurt to localize the main error-messages, also localizing the error *details* has always seemed somewhat unnecessary since those are only intended for debugging/development purposes. However, I can understand why that's done since the GENERIC viewer used to expose this information in the UI; via the `errorWrapper` UI that's removed in PR 15533. At this point, when any errors are simply logged in the console, it no longer seems necessary to keep localizing the error *details* in the default viewer.
2022-10-06 19:21:41 +09:00
console.error(`${message}\n\n${moreInfoText.join("\n")}`);
Firefox extension now use the default loading indicator
2011-09-28 19:53:53 +09:00
},
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
progress(level) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (!this.loadingBar || this.downloadComplete) {
Ensure that the loadingBar isn't displayed again when the entire file has already been fetched This could only (potentially) happen when `disableAutoFetch` is used.
2017-07-29 18:36:45 +09:00
// Don't accidentally show the loading bar again when the entire file has
// already been fetched (only an issue when disableAutoFetch is enabled).
return;
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const percent = Math.round(level * 100);
Only update progress bar if it increases
2013-04-24 02:00:31 +09:00
// When we transition from full request to range requests, it's possible
// that we discard some of the loaded data. This can cause the loading
// bar to move backwards. So prevent this by only updating the bar if it
// increases.
[api-minor] Further modernize the `ProgressBar` class (PR 14918 follow-up) - Simplify how we look-up the DOM-element, which should also be a tiny bit more efficent. - Use private class-fields, rather than property-names prefixed with underscores. - Inline the `#updateBar` helper-method directly in the `percent`-setter, since having a separate method doesn't seem necessary in this case. - Set the `indeterminate`-class on the ProgressBar DOM-element, to simplify the code. Finally, also (slightly) re-factors the `PDFViewerApplication.progress`-method to make it a bit smaller.
2022-07-01 17:14:57 +09:00
if (percent <= this.loadingBar.percent) {
return;
Only update progress bar if it increases
2013-04-24 02:00:31 +09:00
}
[api-minor] Further modernize the `ProgressBar` class (PR 14918 follow-up) - Simplify how we look-up the DOM-element, which should also be a tiny bit more efficent. - Use private class-fields, rather than property-names prefixed with underscores. - Inline the `#updateBar` helper-method directly in the `percent`-setter, since having a separate method doesn't seem necessary in this case. - Set the `indeterminate`-class on the ProgressBar DOM-element, to simplify the code. Finally, also (slightly) re-factors the `PDFViewerApplication.progress`-method to make it a bit smaller.
2022-07-01 17:14:57 +09:00
this.loadingBar.percent = percent;
// When disableAutoFetch is enabled, it's not uncommon for the entire file
// to never be fetched (depends on e.g. the file structure). In this case
// the loading bar will not be completely filled, nor will it be hidden.
// To prevent displaying a partially filled loading bar permanently, we
// hide it when no data has been loaded during a certain amount of time.
Move the `disableAutoFetch` functionality into the `ProgressBar`-class It seems nicer overall, since we're exporting the `ProgressBar` in the viewer-components, to move this functionality into the `ProgressBar`-class itself rather than handling it "manually" in the default-viewer.
2023-01-21 20:29:36 +09:00
if (
[api-minor] Further modernize the `ProgressBar` class (PR 14918 follow-up) - Simplify how we look-up the DOM-element, which should also be a tiny bit more efficent. - Use private class-fields, rather than property-names prefixed with underscores. - Inline the `#updateBar` helper-method directly in the `percent`-setter, since having a separate method doesn't seem necessary in this case. - Set the `indeterminate`-class on the ProgressBar DOM-element, to simplify the code. Finally, also (slightly) re-factors the `PDFViewerApplication.progress`-method to make it a bit smaller.
2022-07-01 17:14:57 +09:00
this.pdfDocument?.loadingParams.disableAutoFetch ??
Move the `disableAutoFetch` functionality into the `ProgressBar`-class It seems nicer overall, since we're exporting the `ProgressBar` in the viewer-components, to move this functionality into the `ProgressBar`-class itself rather than handling it "manually" in the default-viewer.
2023-01-21 20:29:36 +09:00
AppOptions.get("disableAutoFetch")
) {
this.loadingBar.setDisableAutoFetch();
[api-minor] Further modernize the `ProgressBar` class (PR 14918 follow-up) - Simplify how we look-up the DOM-element, which should also be a tiny bit more efficent. - Use private class-fields, rather than property-names prefixed with underscores. - Inline the `#updateBar` helper-method directly in the `percent`-setter, since having a separate method doesn't seem necessary in this case. - Set the `indeterminate`-class on the ProgressBar DOM-element, to simplify the code. Finally, also (slightly) re-factors the `PDFViewerApplication.progress`-method to make it a bit smaller.
2022-07-01 17:14:57 +09:00
}
Firefox extension now use the default loading indicator
2011-09-28 19:53:53 +09:00
},
Remove the ability to pass a `scale` parameter in the (optional) `args` object parameter of `PDFViewerApplication.open(file, args)` Since the very early days of the viewer, it's been possible to pass in a `scale` when opening a PDF file. However, most of the time it was/is actually being ignored, which limits its usefulness considerably. In older versions of the viewer, if a document hash was present (i.e. `PDFViewerApplication.initialBookmark` being set) or if the document existed in the `ViewHistory`, the `scale` passed to `PDFViewerApplication.open` would thus always be ignored. In addition to the above, in the current viewer there's even more cases where the `scale` parameter will be ignored: if a (valid) browser history entry exists on document load, or if the `defaultZoomValue` preference is set to a non-default value. Hence the result is that in most situation, a `scale` passed to `PDFViewerApplication.open` will be completely ignored. A much better, not to mention supported, way of setting the initial scale is by using the `defaultZoomLevel` preference. In comparision, this also has the advantage of being used in situations where the `scale` would be ignored. All in all this leads to the current situation where we have code which is essentially dead, since no part of the viewer (by default) relies on it. To clean up this code, and to avoid having to pass (basically) unused parameters around, I'd thus like to remove the ability to pass a `scale` to `PDFViewerApplication.open`.
2017-08-24 16:24:32 +09:00
load(pdfDocument) {
Use already downloaded data for the open with/save as dialog.
2012-06-02 06:17:09 +09:00
this.pdfDocument = pdfDocument;
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 18:22:02 +09:00
pdfDocument.getDownloadInfo().then(({ length }) => {
this._contentLength = length; // Ensure that the correct length is used.
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
this.downloadComplete = true;
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.loadingBar?.hide();
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
firstPagePromise.then(() => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.eventBus.dispatch("documentloaded", { source: this });
Replace unnecessary `var self = this` statements with arrow functions in `web/app.js` Also replaces `var` with `let` in the functions/methods that are touched in the patch. Please note that this should be completely safe, for two separate reasons, since trying to access `let` in a scope where it's not defined is first of all a runtime error and second of all an ESLint error (thanks to the `no-undef` rule).
2017-05-09 20:17:39 +09:00
});
Implement progressive loading of PDFs
2013-02-07 08:19:29 +09:00
});
Firefox extension now use the default loading indicator
2011-09-28 19:53:53 +09:00
Add support for, the API property, PageMode in the viewer (issue 8657) Note that the PageMode, as specified in the API, will only be honoured when either: the user hasn't set the `sidebarViewOnLoad` preference to a non-default value, or a non-default `sidebarView` entry doesn't exist in the view history, or the "pagemode" hash parameter is included in the URL. Since this is new functionality, the patch also includes a preference (`disablePageMode`), to make it easy to opt-out of this functionality if the user/implementor so wishes.
2017-07-19 23:26:17 +09:00
// Since the `setInitialView` call below depends on this being resolved,
// fetch it early to avoid delaying initial rendering of the PDF document.
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const pageLayoutPromise = pdfDocument.getPageLayout().catch(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
/* Avoid breaking initial rendering; ignoring errors. */
});
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const pageModePromise = pdfDocument.getPageMode().catch(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
/* Avoid breaking initial rendering; ignoring errors. */
});
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const openActionPromise = pdfDocument.getOpenAction().catch(function () {
[api-minor] Add more general OpenAction support (PR 10334 follow-up, issue 11642) This patch deprecates the existing `getOpenActionDestination` API method, in favor of a better and more general `getOpenAction` method instead. (For now JavaScript actions, related to printing, are still handled as before.) By clearly separating "regular" Print actions from the JavaScript handling, it's thus possible to get rid of the somewhat annoying and strictly incorrect warning when the viewer loads.
2020-02-28 22:54:07 +09:00
/* Avoid breaking initial rendering; ignoring errors. */
});
Add support for, the API property, PageMode in the viewer (issue 8657) Note that the PageMode, as specified in the API, will only be honoured when either: the user hasn't set the `sidebarViewOnLoad` preference to a non-default value, or a non-default `sidebarView` entry doesn't exist in the view history, or the "pagemode" hash parameter is included in the URL. Since this is new functionality, the patch also includes a preference (`disablePageMode`), to make it easy to opt-out of this functionality if the user/implementor so wishes.
2017-07-19 23:26:17 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.toolbar?.setPagesCount(pdfDocument.numPages, false);
this.secondaryToolbar?.setPagesCount(pdfDocument.numPages);
Final commit squash
2012-10-11 02:26:41 +09:00
[Firefox] Stop using a `baseUrl` in the `PDFLinkService` (PR 16153 follow-up) With the changes in PR 16153 we're no longer setting a `<base href>` in the Firefox PDF Viewer, hence it shouldn't be necessary to keep setting a `baseUrl` in the `PDFLinkService`-class. Given that the original document URL is now kept, the browser itself will handle relative URLs and we can thus slightly reduce the amount of string parsing required when handling various links in the viewer.
2023-03-30 18:51:25 +09:00
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("CHROME")) {
const baseUrl = location.href.split("#")[0];
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
// Ignore "data:"-URLs for performance reasons, even though it may cause
// internal links to not work perfectly in all cases (see bug 1803050).
[Firefox] Stop using a `baseUrl` in the `PDFLinkService` (PR 16153 follow-up) With the changes in PR 16153 we're no longer setting a `<base href>` in the Firefox PDF Viewer, hence it shouldn't be necessary to keep setting a `baseUrl` in the `PDFLinkService`-class. Given that the original document URL is now kept, the browser itself will handle relative URLs and we can thus slightly reduce the amount of string parsing required when handling various links in the viewer.
2023-03-30 18:51:25 +09:00
this.pdfLinkService.setDocument(
pdfDocument,
isDataScheme(baseUrl) ? null : baseUrl
);
} else {
this.pdfLinkService.setDocument(pdfDocument);
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
}
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfDocumentProperties?.setDocument(pdfDocument);
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const pdfViewer = this.pdfViewer;
Moves pdfDocument.getPage/getTextContent requests out of PDFView
2014-09-15 23:49:24 +09:00
pdfViewer.setDocument(pdfDocument);
Slightly improve the `BaseViewer.{firstPagePromise, onePageRendered, pagesPromise}` functionality There's a couple of issues with this functionality: - The respective `PromiseCapability` instances are not being reset, in `BaseViewer._resetView`, when the document is closed which is inconsistent with all other state. - While the default viewer depends on these promises, and they thus ought to be considered part of e.g. the `PDFViewer` API-surface, they're not really defined in a particularily user-visible way (being that they're attached to the `BaseViewer` instance *inline* in `BaseViewer.setDocument`). - There's some internal `BaseViewer` state, e.g. `BaseViewer._pageViewsReady`, which is tracked manually and could instead be tracked indirectly via the relevant `PromiseCapability`, thus reducing the need to track state *twice* since that's always best to avoid. *Please note:* In the existing implementation, these promises are not defined *until* the `BaseViewer.setDocument` method has been called. While it would've been simple to lift that restriction in this patch, I'm purposely choosing *not* to do so since this ensures that any Promise handlers added inside of `BaseViewer.setDocument` are always invoked *before* any external ones (and keeping that behaviour seems generally reasonable).
2020-03-07 21:11:51 +09:00
const { firstPagePromise, onePageRendered, pagesPromise } = pdfViewer;
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfThumbnailViewer?.setDocument(pdfDocument);
Initial API implementation
2012-04-10 14:20:57 +09:00
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
const storedPromise = (this.store = new ViewHistory(
[api-minor] Support accessing both the original and modified PDF fingerprint The PDF.js API has only ever supported accessing the original file ID, however the second one that (should) exist in *modified* documents have thus far been completely inaccessible through the API. That seems like a simple oversight, caused e.g. by the viewer not needing it, since it really shouldn't hurt to provide API-users with the ability to check if a PDF document has been modified since its creation.[1] Please refer to https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G13.2261661 for additional information. For an example of how to update existing code to use the new API, please see the changes in the `web/app.js` file included in this patch. *Please note:* While I'm not sure if we'll ever be able to remove the old `PDFDocumentProxy.fingerprint` getter, given that it's existed since "forever", that probably isn't a big deal given that it's now limited to only `GENERIC`-builds. --- [1] Although this obviously depends on the PDF software following the specification, by updating the second file ID as intended.
2021-07-02 23:36:27 +09:00
pdfDocument.fingerprints[0]
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
))
.getMultiple({
page: null,
zoom: DEFAULT_SCALE_VALUE,
scrollLeft: "0",
scrollTop: "0",
rotation: null,
sidebarView: SidebarView.UNKNOWN,
scrollMode: ScrollMode.UNKNOWN,
spreadMode: SpreadMode.UNKNOWN,
})
.catch(() => {
/* Unable to read from storage; ignoring errors. */
return Object.create(null);
});
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
firstPagePromise.then(pdfPage => {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.loadingBar?.setWidth(this.appConfig.viewerContainer);
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
this._initializeAnnotationStorageCallbacks(pdfDocument);
Fix the positioning of the progressive loadingBar
2013-07-19 01:28:59 +09:00
Utilize `async`/`await` in `PDFViewerApplication.load` to reduce the number of Promises and temporary variables necessary when setting the initial document location
2018-08-09 22:15:41 +09:00
Promise.all([
Prevent "offsetParent is not set -- cannot scroll" errors when the viewer loads in e.g. a hidden <iframe> Besides avoiding errors during loading, this also ensures that the document will be correctly scrolled/zoomed into view once the viewer becomes visible. This "new" behaviour was always intended, see PR 2613, however various re-factoring over the years seem to have broken this (and I'm probably at least somewhat responsible for that).
2019-09-08 21:13:50 +09:00
animationStarted,
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
storedPromise,
Prevent "offsetParent is not set -- cannot scroll" errors when the viewer loads in e.g. a hidden <iframe> Besides avoiding errors during loading, this also ensures that the document will be correctly scrolled/zoomed into view once the viewer becomes visible. This "new" behaviour was always intended, see PR 2613, however various re-factoring over the years seem to have broken this (and I'm probably at least somewhat responsible for that).
2019-09-08 21:13:50 +09:00
pageLayoutPromise,
pageModePromise,
[api-minor] Add more general OpenAction support (PR 10334 follow-up, issue 11642) This patch deprecates the existing `getOpenActionDestination` API method, in favor of a better and more general `getOpenAction` method instead. (For now JavaScript actions, related to printing, are still handled as before.) By clearly separating "regular" Print actions from the JavaScript handling, it's thus possible to get rid of the somewhat annoying and strictly incorrect warning when the viewer loads.
2020-02-28 22:54:07 +09:00
openActionPromise,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
])
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
.then(async ([timeStamp, stored, pageLayout, pageMode, openAction]) => {
const viewOnLoad = AppOptions.get("viewOnLoad");
Simplify the handling of the `defaultZoomValue` preference in `PDFViewerApplication.load`
2018-06-26 21:08:00 +09:00
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
this._initializePdfHistory({
[api-minor] Support accessing both the original and modified PDF fingerprint The PDF.js API has only ever supported accessing the original file ID, however the second one that (should) exist in *modified* documents have thus far been completely inaccessible through the API. That seems like a simple oversight, caused e.g. by the viewer not needing it, since it really shouldn't hurt to provide API-users with the ability to check if a PDF document has been modified since its creation.[1] Please refer to https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G13.2261661 for additional information. For an example of how to update existing code to use the new API, please see the changes in the `web/app.js` file included in this patch. *Please note:* While I'm not sure if we'll ever be able to remove the old `PDFDocumentProxy.fingerprint` getter, given that it's existed since "forever", that probably isn't a big deal given that it's now limited to only `GENERIC`-builds. --- [1] Although this obviously depends on the PDF software following the specification, by updating the second file ID as intended.
2021-07-02 23:36:27 +09:00
fingerprint: pdfDocument.fingerprints[0],
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
viewOnLoad,
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-06 01:36:28 +09:00
initialDest: openAction?.dest,
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
});
const initialBookmark = this.initialBookmark;
// Initialize the default values, from user preferences.
const zoom = AppOptions.get("defaultZoomValue");
let hash = zoom ? `zoom=${zoom}` : null;
let rotation = null;
let sidebarView = AppOptions.get("sidebarViewOnLoad");
let scrollMode = AppOptions.get("scrollModeOnLoad");
let spreadMode = AppOptions.get("spreadModeOnLoad");
if (stored.page && viewOnLoad !== ViewOnLoad.INITIAL) {
hash =
`page=${stored.page}&zoom=${zoom || stored.zoom},` +
`${stored.scrollLeft},${stored.scrollTop}`;
rotation = parseInt(stored.rotation, 10);
// Always let user preference take precedence over the view history.
if (sidebarView === SidebarView.UNKNOWN) {
sidebarView = stored.sidebarView | 0;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
if (scrollMode === ScrollMode.UNKNOWN) {
scrollMode = stored.scrollMode | 0;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
if (spreadMode === SpreadMode.UNKNOWN) {
spreadMode = stored.spreadMode | 0;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
}
[GeckoView] Introduce a development mode constant to tell the viewers apart Currently we have a couple of pre-processor checks, specifically for the GV-viewer, spread throughout the code. This works fine when *building* the viewer, however they're obviously ignored in development mode (i.e. `gulp server`). This leads to a situation where the GV development viewer, i.e. http://localhost:8888/web/viewer-geckoview.html, behaves subtly different from its built version. This could easily lead to bugs, hence this patch introduces a development mode constant to hopefully improve things here. Finally, in a follow-up to PR 15842, also ignores the `pageMode`-state since there's no sidebar available.
2023-02-08 00:07:12 +09:00
// NOTE: Ignore the pageMode/pageLayout in GeckoView since there's no
// sidebar available, nor any UI for changing the Scroll/Spread modes.
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-07 21:04:41 +09:00
if (
[GeckoView] Introduce a development mode constant to tell the viewers apart Currently we have a couple of pre-processor checks, specifically for the GV-viewer, spread throughout the code. This works fine when *building* the viewer, however they're obviously ignored in development mode (i.e. `gulp server`). This leads to a situation where the GV development viewer, i.e. http://localhost:8888/web/viewer-geckoview.html, behaves subtly different from its built version. This could easily lead to bugs, hence this patch introduces a development mode constant to hopefully improve things here. Finally, in a follow-up to PR 15842, also ignores the `pageMode`-state since there's no sidebar available.
2023-02-08 00:07:12 +09:00
typeof PDFJSDev === "undefined"
? !window.isGECKOVIEW
: !PDFJSDev.test("GECKOVIEW")
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-07 21:04:41 +09:00
) {
[GeckoView] Introduce a development mode constant to tell the viewers apart Currently we have a couple of pre-processor checks, specifically for the GV-viewer, spread throughout the code. This works fine when *building* the viewer, however they're obviously ignored in development mode (i.e. `gulp server`). This leads to a situation where the GV development viewer, i.e. http://localhost:8888/web/viewer-geckoview.html, behaves subtly different from its built version. This could easily lead to bugs, hence this patch introduces a development mode constant to hopefully improve things here. Finally, in a follow-up to PR 15842, also ignores the `pageMode`-state since there's no sidebar available.
2023-02-08 00:07:12 +09:00
// Always let the user preference/view history take precedence.
if (pageMode && sidebarView === SidebarView.UNKNOWN) {
sidebarView = apiPageModeToSidebarView(pageMode);
}
if (
pageLayout &&
scrollMode === ScrollMode.UNKNOWN &&
spreadMode === SpreadMode.UNKNOWN
) {
const modes = apiPageLayoutToViewerModes(pageLayout);
// TODO: Try to improve page-switching when using the mouse-wheel
// and/or arrow-keys before allowing the document to control this.
// scrollMode = modes.scrollMode;
spreadMode = modes.spreadMode;
}
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
}
Simplify the handling of the `defaultZoomValue` preference in `PDFViewerApplication.load`
2018-06-26 21:08:00 +09:00
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
this.setInitialView(hash, {
rotation,
sidebarView,
scrollMode,
spreadMode,
});
this.eventBus.dispatch("documentinit", { source: this });
// Make all navigation keys work on document load,
// unless the viewer is embedded in a web page.
if (!this.isViewerEmbedded) {
pdfViewer.focus();
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts. Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part. At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof. As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately. Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
}
Re-factor `PDFViewerApplication.load` such that `{PDFViewer, PDFThumbnailViewer}.setDocument` happens slightly earlier The `BaseViewer.setDocument` method in particular is necessary for rendering to start when the viewer loads, hence you obviously want that to happen as soon as possible and without any unnecessary delays. Unfortunately *some* API calls need to be done before that, note existing comments, however the `ViewHistory` initialization (and subsequent fetching of data) in particular can be moved slightly without any adverse effects. As part of testing I've used logging with `performance.now()` inserted in various parts of this code, and there's *obviously* no discernible changes between `master` and this patch for e.g. rendering starting in the viewer. *Note:* The vast majority of this patch is simple indentation changes, which were forced by Prettier (and done automatically with `gulp lint --fix`).
2020-03-21 22:37:03 +09:00
// For documents with different page sizes, once all pages are
// resolved, ensure that the correct location becomes visible on load.
// (To reduce the risk, in very large and/or slow loading documents,
// that the location changes *after* the user has started interacting
// with the viewer, wait for either `pagesPromise` or a timeout.)
await Promise.race([
pagesPromise,
new Promise(resolve => {
setTimeout(resolve, FORCE_PAGES_LOADED_TIMEOUT);
}),
]);
if (!initialBookmark && !hash) {
return;
}
if (pdfViewer.hasEqualPageSizes) {
return;
}
this.initialBookmark = initialBookmark;
// eslint-disable-next-line no-self-assign
pdfViewer.currentScaleValue = pdfViewer.currentScaleValue;
// Re-apply the initial document location.
this.setInitialView(hash);
})
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
.catch(() => {
// Ensure that the document is always completely initialized,
// even if there are any errors thrown above.
this.setInitialView();
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
// At this point, rendering of the initial page(s) should always have
// started (and may even have completed).
// To prevent any future issues, e.g. the document being completely
// blank on load, always trigger rendering here.
pdfViewer.update();
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
});
Changes to viewer to support progressive loading
2013-03-09 11:08:37 +09:00
});
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
pagesPromise.then(
() => {
this._unblockDocumentLoadEvent();
[Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553)
2021-02-06 06:00:10 +09:00
Ensure that the viewer handles `BaseViewer` initialization failures *This patch can be tested e.g. with the `poppler-85140-0.pdf` document from the test-suite.* For some sufficiently corrupt documents the `getDocument` call will succeed, but fetching even the very first page fails. Currently we only print error messages (in the console) from the `{BaseViewer, PDFThumbnailViewer}.setDocument` methods, but don't actually provide these errors to allow the viewer to handle them properly. In practice this means that the GENERIC viewer won't display the `errorWrapper`, and in the MOZCENTRAL viewer the *browser* loading indicator is never hidden (since we never unblock the "load" event).
2021-12-05 00:40:48 +09:00
this._initializeAutoPrint(pdfDocument, openActionPromise);
},
reason => {
this.l10n.get("loading_error").then(msg => {
this._documentError(msg, { message: reason?.message });
});
}
);
Avoiding pageRefMap is not defined in the getDestinationHash()
2011-12-01 10:04:45 +09:00
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 20:36:06 +09:00
onePageRendered.then(data => {
this.externalServices.reportTelemetry({
type: "pageInfo",
timestamp: data.timestamp,
});
[GeckoView] Avoid unused outline, attachments, and layers fetching Currently there's no UI for this functionality in the GV-viewer, however we still call the API methods. This potentially leads to a bunch of worker-thread parsing, for PDF documents with these features, despite the result being completely unused. Given that mobile devices are usually more resource constrained than desktop/laptop computers, not to mentioned battery life, we can avoid doing work that'll just be ignored anyway.
2023-02-07 20:30:05 +09:00
if (this.pdfOutlineViewer) {
pdfDocument.getOutline().then(outline => {
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the outline resolved.
}
this.pdfOutlineViewer.render({ outline, pdfDocument });
});
}
if (this.pdfAttachmentViewer) {
pdfDocument.getAttachments().then(attachments => {
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the attachments resolved.
}
this.pdfAttachmentViewer.render({ attachments });
});
}
if (this.pdfLayerViewer) {
// Ensure that the layers accurately reflects the current state in the
// viewer itself, rather than the default state provided by the API.
pdfViewer.optionalContentConfigPromise.then(optionalContentConfig => {
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the layers resolved.
}
this.pdfLayerViewer.render({ optionalContentConfig, pdfDocument });
});
}
Initial API implementation
2012-04-10 14:20:57 +09:00
});
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
this._initializePageLabels(pdfDocument);
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
this._initializeMetadata(pdfDocument);
JS - Add the basic architecture to be able to execute embedded js
2020-10-01 20:57:23 +09:00
},
/**
* @private
*/
[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 08:15:18 +09:00
async _scriptingDocProperties(pdfDocument) {
Stop re-fetching the `metadata` unconditionally in `PDFViewerApplication._initializeJavaScript` We can easily avoid unnecessary API-calls here, since most of the time the `metadata` will already be available here. In the *rare* case that it's not available, we can simply wait for the existing `getMetadata`-call to resolve.
2020-12-06 20:42:56 +09:00
if (!this.documentInfo) {
// It should be *extremely* rare for metadata to not have been resolved
// when this code runs, but ensure that we handle that case here.
await new Promise(resolve => {
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 20:37:37 +09:00
this.eventBus._on("metadataloaded", resolve, { once: true });
Stop re-fetching the `metadata` unconditionally in `PDFViewerApplication._initializeJavaScript` We can easily avoid unnecessary API-calls here, since most of the time the `metadata` will already be available here. In the *rare* case that it's not available, we can simply wait for the existing `getMetadata`-call to resolve.
2020-12-06 20:42:56 +09:00
});
if (pdfDocument !== this.pdfDocument) {
[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 08:15:18 +09:00
return null; // The document was closed while the metadata resolved.
Stop re-fetching the `metadata` unconditionally in `PDFViewerApplication._initializeJavaScript` We can easily avoid unnecessary API-calls here, since most of the time the `metadata` will already be available here. In the *rare* case that it's not available, we can simply wait for the existing `getMetadata`-call to resolve.
2020-12-06 20:42:56 +09:00
}
}
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 18:22:02 +09:00
if (!this._contentLength) {
// Always waiting for the entire PDF document to be loaded will, most
// likely, delay sandbox-creation too much in the general case for all
// PDF documents which are not provided as binary data to the API.
// Hence we'll simply have to trust that the `contentLength` (as provided
// by the server), when it exists, is accurate enough here.
await new Promise(resolve => {
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 20:37:37 +09:00
this.eventBus._on("documentloaded", resolve, { once: true });
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 18:22:02 +09:00
});
if (pdfDocument !== this.pdfDocument) {
[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 08:15:18 +09:00
return null; // The document was closed while the downloadInfo resolved.
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 18:22:02 +09:00
}
}
JS - Add the basic architecture to be able to execute embedded js
2020-10-01 20:57:23 +09:00
[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 08:15:18 +09:00
return {
...this.documentInfo,
baseURL: this.baseUrl,
filesize: this._contentLength,
filename: this._docFilename,
metadata: this.metadata?.getRaw(),
authors: this.metadata?.get("dc:creator"),
numPages: this.pagesCount,
URL: this.url,
JS -- Send events to the sandbox from annotation layer
2020-11-18 22:59:57 +09:00
};
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
},
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
/**
* @private
*/
async _initializeAutoPrint(pdfDocument, openActionPromise) {
const [openAction, javaScript] = await Promise.all([
openActionPromise,
[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 08:15:18 +09:00
!this.pdfViewer.enableScripting ? pdfDocument.getJavaScript() : null,
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
]);
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the auto print data resolved.
}
let triggerAutoPrint = false;
Avoid the `getJavaScript` API-call in `PDFViewerApplication._initializeAutoPrint` when "enableScripting" is set Rather than calling `getJavaScript` in the API and then ignoring the result, when "enableScripting" is set, it should be more efficient/faster to simply skip it altogether instead. Finally, the `setTimeout` call at the end of `PDFViewerApplication._initializeAutoPrint` is removed, since it doesn't seem necessary any more as far as I can tell.[1] Note that when this functionality was originally added, back in PR 2839, it seems that `pagesPromise` simply waited for the `getPage` calls of *all* pages to resolve. Today, on the other hand, the viewer fetches *and* renders the first page *before* doing the remaining `getPage` calls, and only afterwards is `pagesPromise` resolved. Hence it's not really clear why we now need to delay printing even further with a `setTimeout` call. --- [1] The patch was tested with the following documents: https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug1001080.pdf and https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6106.pdf
2020-12-21 19:43:54 +09:00
if (openAction?.action === "Print") {
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
triggerAutoPrint = true;
}
Avoid the `getJavaScript` API-call in `PDFViewerApplication._initializeAutoPrint` when "enableScripting" is set Rather than calling `getJavaScript` in the API and then ignoring the result, when "enableScripting" is set, it should be more efficient/faster to simply skip it altogether instead. Finally, the `setTimeout` call at the end of `PDFViewerApplication._initializeAutoPrint` is removed, since it doesn't seem necessary any more as far as I can tell.[1] Note that when this functionality was originally added, back in PR 2839, it seems that `pagesPromise` simply waited for the `getPage` calls of *all* pages to resolve. Today, on the other hand, the viewer fetches *and* renders the first page *before* doing the remaining `getPage` calls, and only afterwards is `pagesPromise` resolved. Hence it's not really clear why we now need to delay printing even further with a `setTimeout` call. --- [1] The patch was tested with the following documents: https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug1001080.pdf and https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6106.pdf
2020-12-21 19:43:54 +09:00
if (javaScript) {
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
javaScript.some(js => {
if (!js) {
// Don't warn/fallback for empty JavaScript actions.
return false;
}
Remove the `PDFViewerApplication._delayedFallback` functionality According to a decision by UX and PM, please see https://bugzilla.mozilla.org/show_bug.cgi?id=1705060#c2 (and implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1705327), we no longer show the notification-bar in Firefox; hence the special `PDFViewerApplication._delayedFallback` functionality should no longer be necessary. Furthermore, note that at this point in time *most* of the features which used the `PDFViewerApplication._delayedFallback` functionality is now enabled by default; hence that provides even less reason to keep this code around and existing calls are thus converted to "regular" `PDFViewerApplication.fallback` calls.
2021-04-16 17:08:13 +09:00
console.warn("Warning: JavaScript support is not enabled");
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
return true;
});
if (!triggerAutoPrint) {
// Hack to support auto printing.
for (const js of javaScript) {
if (js && AutoPrintRegExp.test(js)) {
triggerAutoPrint = true;
break;
}
}
}
}
if (triggerAutoPrint) {
Avoid the `getJavaScript` API-call in `PDFViewerApplication._initializeAutoPrint` when "enableScripting" is set Rather than calling `getJavaScript` in the API and then ignoring the result, when "enableScripting" is set, it should be more efficient/faster to simply skip it altogether instead. Finally, the `setTimeout` call at the end of `PDFViewerApplication._initializeAutoPrint` is removed, since it doesn't seem necessary any more as far as I can tell.[1] Note that when this functionality was originally added, back in PR 2839, it seems that `pagesPromise` simply waited for the `getPage` calls of *all* pages to resolve. Today, on the other hand, the viewer fetches *and* renders the first page *before* doing the remaining `getPage` calls, and only afterwards is `pagesPromise` resolved. Hence it's not really clear why we now need to delay printing even further with a `setTimeout` call. --- [1] The patch was tested with the following documents: https://github.com/mozilla/pdf.js/blob/master/test/pdfs/bug1001080.pdf and https://github.com/mozilla/pdf.js/blob/master/test/pdfs/issue6106.pdf
2020-12-21 19:43:54 +09:00
this.triggerPrinting();
Move the initialization of "auto print" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "auto print" out into its own (private) helper method instead.
2020-04-05 17:59:10 +09:00
}
},
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
/**
* @private
*/
async _initializeMetadata(pdfDocument) {
Account for formatting changes in Prettier version `2.3.0` With the exception of one tweaked `eslint-disable` comment, in `web/generic_scripting.js`, this patch was generated automatically using `gulp lint --fix`. Please find additional information at: - https://github.com/prettier/prettier/releases/tag/2.3.0 - https://prettier.io/blog/2021/05/09/2.3.0.html
2021-05-16 17:58:34 +09:00
const { info, metadata, contentDispositionFilename, contentLength } =
await pdfDocument.getMetadata();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the metadata resolved.
}
this.documentInfo = info;
this.metadata = metadata;
[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-24 21:02:58 +09:00
this._contentDispositionFilename ??= contentDispositionFilename;
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 18:22:02 +09:00
this._contentLength ??= contentLength; // See `getDownloadInfo`-call above.
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
// Provides some basic debug information
console.log(
[api-minor] Support accessing both the original and modified PDF fingerprint The PDF.js API has only ever supported accessing the original file ID, however the second one that (should) exist in *modified* documents have thus far been completely inaccessible through the API. That seems like a simple oversight, caused e.g. by the viewer not needing it, since it really shouldn't hurt to provide API-users with the ability to check if a PDF document has been modified since its creation.[1] Please refer to https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#G13.2261661 for additional information. For an example of how to update existing code to use the new API, please see the changes in the `web/app.js` file included in this patch. *Please note:* While I'm not sure if we'll ever be able to remove the old `PDFDocumentProxy.fingerprint` getter, given that it's existed since "forever", that probably isn't a big deal given that it's now limited to only `GENERIC`-builds. --- [1] Although this obviously depends on the PDF software following the specification, by updating the second file ID as intended.
2021-07-02 23:36:27 +09:00
`PDF ${pdfDocument.fingerprints[0]} [${info.PDFFormatVersion} ` +
A couple of small improvements of the `PDFViewerApplication.{_initializeMetadata, _initializePdfHistory}` methods - Use template strings when printing document/viewer information in `_initializeMetadata`, since the old format feels overly verbose. Also, get the WebGL state from the `BaseViewer` instance[1] rather than the `AppOptions`. Since the `AppOptions` value could theoretically have been changed (by the user) after the viewer components were initialized, it seems much more useful to print the *actual* value that'll be used during rendering. - Change `_initializePdfHistory` to actually do the "is embedded"-check first, in accordance with the comment and given that the "disableHistory" option usually shouldn't be set. --- [1] Admittedly reaching into the `BaseViewer` instance and just grabbing the value perhaps isn't a great approach overall, but given that the WebGL-backend isn't even on by default this probably doesn't matter too much.
2020-04-05 18:15:21 +09:00
`${(info.Producer || "-").trim()} / ${(info.Creator || "-").trim()}] ` +
Log the `build` number, in addition to the `version`, in the viewer Given that the `build` number allows you to *directly* find the relevant commit, it cannot hurt to log that one as well.
2022-10-06 19:03:22 +09:00
`(PDF.js: ${version || "?"} [${build || "?"}])`
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
);
Ensure that the `contentDispositionFilename` is always respected, when setting the document title (PR 13014 follow-up) Currently, when range-requests and/or streaming are not supported or for documents opened from `data`-URLs, we'll manually set the `contentDispositionFilename` (assuming it exists and is valid) from the `onOpenWithData`-callback in `PDFViewerApplication.initPassiveLoading`. However, because of a small oversight in `PDFViewerApplication._initializeMetadata`, this *cached* `contentDispositionFilename` would be ignored and we'd only attempt to use the one returned by `PDFDocumentProxy.getMetadata` in the API (which in the cases outlined above will always be empty). Also, to ensure that the document properties dialog always displays the *correct* fileName we'll now lookup it using the same exact method as in the viewer itself (via a new callback-function).
2022-05-28 18:05:40 +09:00
let pdfTitle = info.Title;
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-16 22:13:39 +09:00
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-06 01:36:28 +09:00
const metadataTitle = metadata?.get("dc:title");
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
if (metadataTitle) {
// Ghostscript can produce invalid 'dc:title' Metadata entries:
// - The title may be "Untitled" (fixes bug 1031612).
// - The title may contain incorrectly encoded characters, which thus
Ensure that the `contentDispositionFilename` is always respected, when setting the document title (PR 13014 follow-up) Currently, when range-requests and/or streaming are not supported or for documents opened from `data`-URLs, we'll manually set the `contentDispositionFilename` (assuming it exists and is valid) from the `onOpenWithData`-callback in `PDFViewerApplication.initPassiveLoading`. However, because of a small oversight in `PDFViewerApplication._initializeMetadata`, this *cached* `contentDispositionFilename` would be ignored and we'd only attempt to use the one returned by `PDFDocumentProxy.getMetadata` in the API (which in the cases outlined above will always be empty). Also, to ensure that the document properties dialog always displays the *correct* fileName we'll now lookup it using the same exact method as in the viewer itself (via a new callback-function).
2022-05-28 18:05:40 +09:00
// looks broken, hence we ignore the Metadata entry when it contains
// characters from the Specials Unicode block (fixes bug 1605526).
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
if (
metadataTitle !== "Untitled" &&
!/[\uFFF0-\uFFFF]/g.test(metadataTitle)
) {
pdfTitle = metadataTitle;
}
}
if (pdfTitle) {
this.setTitle(
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
`${pdfTitle} - ${this._contentDispositionFilename || this._title}`
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
);
Ensure that the `contentDispositionFilename` is always respected, when setting the document title (PR 13014 follow-up) Currently, when range-requests and/or streaming are not supported or for documents opened from `data`-URLs, we'll manually set the `contentDispositionFilename` (assuming it exists and is valid) from the `onOpenWithData`-callback in `PDFViewerApplication.initPassiveLoading`. However, because of a small oversight in `PDFViewerApplication._initializeMetadata`, this *cached* `contentDispositionFilename` would be ignored and we'd only attempt to use the one returned by `PDFDocumentProxy.getMetadata` in the API (which in the cases outlined above will always be empty). Also, to ensure that the document properties dialog always displays the *correct* fileName we'll now lookup it using the same exact method as in the viewer itself (via a new callback-function).
2022-05-28 18:05:40 +09:00
} else if (this._contentDispositionFilename) {
this.setTitle(this._contentDispositionFilename);
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
}
Adds initial telemetry probes
2013-08-16 23:53:05 +09:00
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 18:41:22 +09:00
if (
info.IsXFAPresent &&
!info.IsAcroFormPresent &&
!pdfDocument.isPureXfa
) {
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 22:02:24 +09:00
if (pdfDocument.loadingParams.enableXfa) {
console.warn("Warning: XFA Foreground documents are not supported");
} else {
console.warn("Warning: XFA support is not enabled");
}
Enable renderInteractiveForms by default.
2020-08-13 01:17:58 +09:00
} else if (
Redo the form type detection logic and include unit tests Good form type detection is important to get reliable telemetry and to only show the fallback bar if a form cannot be filled out by the user. PDF.js only supports AcroForm data, so XFA data is explicitly unsupported (tracked in issue #2373). However, the previous form type detection couldn't separate AcroForm and XFA well enough, causing form type telemetry to be incorrect sometimes and the fallback bar to be shown for forms that could in fact be filled out by the user. The solution in this commit is found by studying the specification and the form documents that are available to us. In a nutshell the rules are: - There is XFA data if the `XFA` entry is a non-empty array or stream. - There is AcroForm data if the `Fields` entry is a non-empty array and it doesn't consist of only document signatures. The document signatures part was not handled in the old code, causing a document with only XFA data to also be marked as having AcroForm data. Moreover, the old code didn't check all the data types. Now that AcroForm and XFA can be distinguished, the viewer is configured to only show the fallback bar for documents that only have XFA data. If a document also has AcroForm data, the viewer can use that to render the form. We have not found documents where the XFA data was necessary in that case. Finally, we include unit tests to ensure that all cases are covered and move the form type detection out of the `parse` function so that it's only executed if the document information is actually requested (potentially making initial parsing a tiny bit faster).
2020-08-23 21:04:49 +09:00
(info.IsAcroFormPresent || info.IsXFAPresent) &&
[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-08 21:36:28 +09:00
!this.pdfViewer.renderForms
Enable renderInteractiveForms by default.
2020-08-13 01:17:58 +09:00
) {
Redo the form type detection logic and include unit tests Good form type detection is important to get reliable telemetry and to only show the fallback bar if a form cannot be filled out by the user. PDF.js only supports AcroForm data, so XFA data is explicitly unsupported (tracked in issue #2373). However, the previous form type detection couldn't separate AcroForm and XFA well enough, causing form type telemetry to be incorrect sometimes and the fallback bar to be shown for forms that could in fact be filled out by the user. The solution in this commit is found by studying the specification and the form documents that are available to us. In a nutshell the rules are: - There is XFA data if the `XFA` entry is a non-empty array or stream. - There is AcroForm data if the `Fields` entry is a non-empty array and it doesn't consist of only document signatures. The document signatures part was not handled in the old code, causing a document with only XFA data to also be marked as having AcroForm data. Moreover, the old code didn't check all the data types. Now that AcroForm and XFA can be distinguished, the viewer is configured to only show the fallback bar for documents that only have XFA data. If a document also has AcroForm data, the viewer can use that to render the form. We have not found documents where the XFA data was necessary in that case. Finally, we include unit tests to ensure that all cases are covered and move the form type detection out of the `parse` function so that it's only executed if the document information is actually requested (potentially making initial parsing a tiny bit faster).
2020-08-23 21:04:49 +09:00
console.warn("Warning: Interactive form support is not enabled");
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
}
[Firefox] Ensure that telemetry will be correctly recorded even when the PDF header is missing (bug 1606566) As suggested in the bug we'll now always fallback to "other", which should be fine considering that that value is listed in the histogram definition; see https://searchfox.org/mozilla-central/rev/331f0c3b25089c9a16be65f4dc8c601aeaac8cc4/toolkit/components/telemetry/Histograms.json#9097-9106 Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1606566
2020-01-02 04:41:15 +09:00
Display widget signature - but don't validate them for now; - Firefox will display a bar to warn that the signature validation is not supported (see https://bugzilla.mozilla.org/show_bug.cgi?id=854315) - almost all (all ?) pdf readers display signatures; - validation is done in edge but for now it's behind a pref.
2021-04-10 23:53:17 +09:00
if (info.IsSignaturesPresent) {
console.warn("Warning: Digital signatures validation is not supported");
Move the initialization of "metadata" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "metadata" out into its own (private) helper method instead.
2020-04-05 17:26:55 +09:00
}
Dispatch a `metadataloaded` event once the `PDFViewerApplication._initializeMetadata` method is done This will be useful in the following patch, and note that there's also an old issue (see 5765) which asked for such an event. However, given that the use-case wasn't *clearly* specified, and that we didn't have an internal use for it at the time it wasn't implemented. Also, ensure that all of the metadata-related properties are actually reset when the document is closed.
2020-12-06 20:30:33 +09:00
this.eventBus.dispatch("metadataloaded", { source: this });
Initial API implementation
2012-04-10 14:20:57 +09:00
},
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
/**
* @private
*/
async _initializePageLabels(pdfDocument) {
[GeckoView] Skip fetching/parsing of pageLabels Currently there's no toolbar in the GV-viewer, hence invoking the pageLabels functionality isn't meaningful and just leads to unnecessary parsing on both the main- and worker-threads. (And if a toolbar is added at some point, it's not clear to me if we'd want to support pageLabels in the GV-viewer anyway.)
2023-02-08 00:20:27 +09:00
if (
typeof PDFJSDev === "undefined"
? window.isGECKOVIEW
: PDFJSDev.test("GECKOVIEW")
) {
return;
}
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
const labels = await pdfDocument.getPageLabels();
if (pdfDocument !== this.pdfDocument) {
return; // The document was closed while the page labels resolved.
}
if (!labels || AppOptions.get("disablePageLabels")) {
return;
}
const numLabels = labels.length;
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 20:43:19 +09:00
// Ignore page labels that correspond to standard page numbering,
// or page labels that are all empty.
let standardLabels = 0,
emptyLabels = 0;
for (let i = 0; i < numLabels; i++) {
const label = labels[i];
if (label === (i + 1).toString()) {
standardLabels++;
} else if (label === "") {
emptyLabels++;
} else {
break;
}
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
}
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 20:43:19 +09:00
if (standardLabels >= numLabels || emptyLabels >= numLabels) {
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
return;
}
const { pdfViewer, pdfThumbnailViewer, toolbar } = this;
pdfViewer.setPageLabels(labels);
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
pdfThumbnailViewer?.setPageLabels(labels);
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
// Changing toolbar page display to use labels and we need to set
// the label of the current page.
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
toolbar?.setPagesCount(numLabels, true);
toolbar?.setPageNumber(
Move the initialization of "page labels" out of `PDFViewerApplication.load` Over time, with more and more API-functionality added, the `PDFViewerApplication.load` method has become quite large and complex. In an attempt to improve the current situation somewhat, this patch moves the fetching and initialization of "page labels" out into its own (private) helper method instead.
2020-04-05 17:24:02 +09:00
pdfViewer.currentPageNumber,
pdfViewer.currentPageLabel
);
},
Move the `PDFHistory` initialization into a helper method in `PDFViewerApplication` This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
2019-02-02 18:08:56 +09:00
/**
* @private
*/
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
_initializePdfHistory({ fingerprint, viewOnLoad, initialDest = null }) {
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 21:21:15 +09:00
if (!this.pdfHistory) {
Move the `PDFHistory` initialization into a helper method in `PDFViewerApplication` This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
2019-02-02 18:08:56 +09:00
return;
}
this.pdfHistory.initialize({
fingerprint,
resetHistory: viewOnLoad === ViewOnLoad.INITIAL,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
updateUrl: AppOptions.get("historyUpdateUrl"),
Move the `PDFHistory` initialization into a helper method in `PDFViewerApplication` This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
2019-02-02 18:08:56 +09:00
});
if (this.pdfHistory.initialBookmark) {
this.initialBookmark = this.pdfHistory.initialBookmark;
this.initialRotation = this.pdfHistory.initialRotation;
}
// Always let the browser history/document hash take precedence.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
initialDest &&
!this.initialBookmark &&
viewOnLoad === ViewOnLoad.UNKNOWN
) {
Move the `PDFHistory` initialization into a helper method in `PDFViewerApplication` This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
2019-02-02 18:08:56 +09:00
this.initialBookmark = JSON.stringify(initialDest);
// TODO: Re-factor the `PDFHistory` initialization to remove this hack
// that's currently necessary to prevent weird initial history state.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.pdfHistory.push({ explicitDest: initialDest, pageNumber: null });
Move the `PDFHistory` initialization into a helper method in `PDFViewerApplication` This avoids having the initialization code "spread out", and will become even simpler once the `TODO` is addressed (which I'm planning on fixing as soon as possible).
2019-02-02 18:08:56 +09:00
}
},
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
/**
* @private
*/
_initializeAnnotationStorageCallbacks(pdfDocument) {
if (pdfDocument !== this.pdfDocument) {
return;
}
const { annotationStorage } = pdfDocument;
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
annotationStorage.onSetModified = () => {
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
window.addEventListener("beforeunload", beforeUnload);
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
this._annotationStorageModified = true;
}
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
};
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
annotationStorage.onResetModified = () => {
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
window.removeEventListener("beforeunload", beforeUnload);
[GENERIC viewer] Avoid data loss in forms, by triggering saving when the document is closed (issue 12257) As discussed in the issue, this is a small/simple patch that should help to prevent *outright* data loss in forms when a new document is opened in the GENERIC viewer. While the implementation is perhaps a bit "simplistic", it does seem to work and should be fine given that this is an edge-case only relevant for the GENERIC viewer.
2021-04-03 22:36:34 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
delete this._annotationStorageModified;
}
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
};
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
annotationStorage.onAnnotationEditor = typeStr => {
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
this._hasAnnotationEditors = !!typeStr;
this.setTitle();
if (typeStr) {
this.externalServices.reportTelemetry({
type: "editing",
data: { type: typeStr },
});
}
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
};
Delay initialization of the `AnnotationStorage` callbacks slightly in the default viewer These callbacks should not be necessary *before* the document has been initialized. Furthermore, move the functionality to a new helper-method since `PDFViewerApplication.load` is already quite large.
2020-12-19 20:49:12 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
setInitialView(
storedHash,
{ rotation, sidebarView, scrollMode, spreadMode } = {}
) {
const setRotation = angle => {
Store the rotation in the `ViewHistory` (issue 5927)
2017-08-21 18:22:07 +09:00
if (isValidRotation(angle)) {
this.pdfViewer.pagesRotation = angle;
}
};
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts. Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part. At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof. As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately. Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
const setViewerModes = (scroll, spread) => {
if (isValidScrollMode(scroll)) {
Replace `setScrollMode`/`setSpreadMode` methods with getters/setters Since all the other viewer methods use the getter/setter pattern, e.g. for setting page/scale/rotation, the way that the Scroll/Spread modes are set thus stands out. For consistency, this really ought to use the same pattern as the rest of the `BaseViewer`. (To avoid breaking third-party implementations, the old methods are kept around as aliases.)
2018-06-29 22:07:42 +09:00
this.pdfViewer.scrollMode = scroll;
Allow the `scrollModeOnLoad`/`spreadModeOnLoad` Preferences to override ViewHistory settings Note how the other "...OnLoad" preferences will allow a *non-default* value to always override a history entry. To improve overall consistency for the viewer options, and to reduce possibly confusing behaviour, this patch changes the `scrollModeOnLoad`/`spreadModeOnLoad` preferences to behave as all the other ones.
2018-06-29 20:16:00 +09:00
}
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts. Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part. At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof. As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately. Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
if (isValidSpreadMode(spread)) {
Replace `setScrollMode`/`setSpreadMode` methods with getters/setters Since all the other viewer methods use the getter/setter pattern, e.g. for setting page/scale/rotation, the way that the Scroll/Spread modes are set thus stands out. For consistency, this really ought to use the same pattern as the rest of the `BaseViewer`. (To avoid breaking third-party implementations, the old methods are kept around as aliases.)
2018-06-29 22:07:42 +09:00
this.pdfViewer.spreadMode = spread;
Allow the `scrollModeOnLoad`/`spreadModeOnLoad` Preferences to override ViewHistory settings Note how the other "...OnLoad" preferences will allow a *non-default* value to always override a history entry. To improve overall consistency for the viewer options, and to reduce possibly confusing behaviour, this patch changes the `scrollModeOnLoad`/`spreadModeOnLoad` preferences to behave as all the other ones.
2018-06-29 20:16:00 +09:00
}
};
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
this.isInitialViewSet = true;
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfSidebar?.setInitialView(sidebarView);
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
Modify a number of the viewer preferences, whose current default value is `0`, such that they behave as expected with the view history The intention with preferences such as `sidebarViewOnLoad`/`scrollModeOnLoad`/`spreadModeOnLoad` were always that they should be able to *unconditionally* override their view history counterparts. Due to the way that these preferences were initially implemented[1], trying to e.g. force the sidebar to remain hidden on load cannot be guaranteed[2]. The reason for this is the use of "enumeration values" containing zero, which in hindsight was an unfortunate choice on my part. At this point it's also not as simple as just re-numbering the affected structures, since that would wreak havoc on existing (modified) preferences. The only reasonable solution that I was able to come up with was to change the *default* values of the preferences themselves, but not their actual values or the meaning thereof. As part of the refactoring, the `disablePageMode` preference was combined with the *adjusted* `sidebarViewOnLoad` one, to hopefully reduce confusion by not tracking related state separately. Additionally, the `showPreviousViewOnLoad` and `disableOpenActionDestination` preferences were combined into a *new* `viewOnLoad` enumeration preference, to further avoid tracking related state separately.
2019-01-27 20:07:38 +09:00
setViewerModes(scrollMode, spreadMode);
Rip out the current implementation of `PDFHistory` The current implementation of `PDFHistory` contains a number of smaller bugs, which are *very* difficult to address without breaking other parts of its code. Possibly the main issue with the current implementation, is that I wrote it quite some time ago, and at the time my understanding of the various edge-cases the code has to deal with was quite limited. Currently `PDFHistory` may, despite most of those cases being fixed, in certain edge-cases lock-up the browser history, essentially preventing the user from navigating back/forward. Hence rather than trying to iterate on `PDFHistory` to make it better, the only viable approach is unfortunately rip it out in its entirety and re-write it from scratch.
2017-07-14 21:24:32 +09:00
if (this.initialBookmark) {
Store the rotation in the `PDFHistory`
2017-08-21 18:56:49 +09:00
setRotation(this.initialRotation);
delete this.initialRotation;
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
this.pdfLinkService.setHash(this.initialBookmark);
Making all link bookmark-able (ref #574, #428); removing always-changing hash
2011-10-02 03:54:37 +09:00
this.initialBookmark = null;
PDF browsing history - v6.50
2013-05-16 07:31:17 +09:00
} else if (storedHash) {
Store the rotation in the `ViewHistory` (issue 5927)
2017-08-21 18:22:07 +09:00
setRotation(rotation);
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
this.pdfLinkService.setHash(storedHash);
Fixes concurrent pages loading (#974 and #626)
2011-12-29 10:18:55 +09:00
}
Fixing initial scale when named destination is specified
2012-01-26 12:52:10 +09:00
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
// Ensure that the correct page number is displayed in the UI,
// even if the active page didn't change during document load.
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.toolbar?.setPageNumber(
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.pdfViewer.currentPageNumber,
this.pdfViewer.currentPageLabel
);
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.secondaryToolbar?.setPageNumber(this.pdfViewer.currentPageNumber);
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
Using pdfjs-dist as a library for b2g viewer.
2015-03-15 04:07:17 +09:00
if (!this.pdfViewer.currentScaleValue) {
Fixing initial scale when named destination is specified
2012-01-26 12:52:10 +09:00
// Scale was not initialized: invalid bookmark or scale was not specified.
// Setting the default one.
Remove `PDFViewerApplication.setScale` and further simplify the `scalechange` event handler (issue 6158) This finally fixes 6158.
2015-07-11 18:47:45 +09:00
this.pdfViewer.currentScaleValue = DEFAULT_SCALE_VALUE;
Fixing initial scale when named destination is specified
2012-01-26 12:52:10 +09:00
}
Making all link bookmark-able (ref #574, #428); removing always-changing hash
2011-10-02 03:54:37 +09:00
},
[api-minor] Add an option, in `PDFDocumentProxy.cleanup`, to allow fonts to remain attached to the DOM As mentioned in the JSDoc comment, this should not be used unless you know what you're doing, since it will lead to increased memory usage. However, in some situations (e.g. SVG-rendering), we still want to be able to run general clean-up on both the main/worker-thread while keeping loaded fonts attached to the DOM.[1] As part of these changes, `WorkerTransport.startCleanup` is converted to an async method and we'll also skip clean-up when destruction has started (since it's redundant). --- [1] The SVG-rendering mode is obviously not officially supported, since it's both rather incomplete and inherently slower. However with recent changes, whereby we cache repeated images on the document rather than the page level, memory usage can be *a lot* worse than before if we never attempt to release e.g. cached image-data when the viewer is in SVG-rendering mode.
2021-04-02 19:26:39 +09:00
/**
* @private
*/
_cleanup() {
Fixes PDFViewerApplication.open/close methods signature.
2015-10-23 22:49:02 +09:00
if (!this.pdfDocument) {
return; // run cleanup when document is loaded
}
Moves viewer code into PDFViewer and some code from PageView.
2014-09-13 11:27:45 +09:00
this.pdfViewer.cleanup();
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfThumbnailViewer?.cleanup();
Adds SVG rendering capabilities to the PDFViewer.
2016-11-19 04:03:49 +09:00
Limit more SVG-specific code to the GENERIC viewer Given that the SVG back-end is not defined anywhere except in GENERIC builds, we can remove a little bit more unnecessary code in e.g. the Firefox PDF Viewer.
2022-07-16 17:31:25 +09:00
if (
typeof PDFJSDev === "undefined" ||
PDFJSDev.test("!PRODUCTION || GENERIC")
) {
// We don't want to remove fonts used by active page SVGs.
this.pdfDocument.cleanup(
/* keepLoadedFonts = */ this.pdfViewer.renderer === RendererType.SVG
);
} else {
this.pdfDocument.cleanup();
}
Change to priority rendering.
2012-06-19 01:48:47 +09:00
},
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
forceRendering() {
Re-factor how printing is triggered in the default viewer This adds a new `PDFViewerApplication.triggerPrinting` method, which takes care of checking that printing is actually supported before calling `window.print`, to remove the need to duplicate that code in multiple places. Also, removes the `PDFViewerApplication.printing` getter since it's not really necessary any more.
2020-09-30 22:02:11 +09:00
this.pdfRenderingQueue.printing = !!this.printService;
Account for formatting changes in Prettier version `2.3.0` With the exception of one tweaked `eslint-disable` comment, in `web/generic_scripting.js`, this patch was generated automatically using `gulp lint --fix`. Please find additional information at: - https://github.com/prettier/prettier/releases/tag/2.3.0 - https://prettier.io/blog/2021/05/09/2.3.0.html
2021-05-16 17:58:34 +09:00
this.pdfRenderingQueue.isThumbnailViewEnabled =
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
this.pdfSidebar?.visibleView === SidebarView.THUMBS;
Moves rendering queue logic from PDFView
2014-09-16 01:18:28 +09:00
this.pdfRenderingQueue.renderHighestPriority();
Change to priority rendering.
2012-06-19 01:48:47 +09:00
},
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
beforePrint() {
[api-minor] Introduce a `PrintAnnotationStorage` with *frozen* serializable data Given that printing is triggered *synchronously* in browsers, it's thus possible for scripting (in PDF documents) to modify the Annotation-data while printing is currently ongoing. To work-around that we add a new printing-specific `AnnotationStorage`, where the serializable data is *frozen* upon initialization, which the viewer can thus create/utilize during printing.
2022-06-13 20:35:58 +09:00
this._printAnnotationStoragePromise = this.pdfScriptingManager
.dispatchWillPrint()
.catch(() => {
/* Avoid breaking printing; ignoring errors. */
})
.then(() => {
return this.pdfDocument?.annotationStorage.print;
});
[Scripting] Try to ensure that the `WillPrint`/`DidPrint` respectively `DidSave` events are always dispatched Note that currently the `DidSave` event is not *guaranteed* to actually be dispatched if there's any errors during saving, which is easily fixed by simply moving it to occur in the `finally`-handler in `PDFViewerApplication.save` method. For the `WillPrint`/`DidPrint` events, things are unfortunately more complicated. Currently these events will *only* be dispatched iff the printing request comes from within the viewer itself (e.g. by the user clicking on the "Print" toolbar button), however printing can be triggered in a few additional ways: - In the GENERIC viewer: - By the <kbd>Ctrl</kbd>+<kbd>P</kbd> keyboard shortcut. - In the MOZCENTRAL viewer, i.e. the Firefox built-in viewer: - By the <kbd>Ctrl</kbd>+<kbd>P</kbd> keyboard shortcut. - By the "Print" item, as found in either the Firefox "Hamburger menu" or in the browser-window menu. In either of the cases described above, no `WillPrint`/`DidPrint` events will be dispatched. In order to *guarantee* that things work in the general case, we thus have to move the `dispatchEventInSandbox` calls to the "beforeprint"/"afterprint" event handlers instead.
2020-12-23 19:13:43 +09:00
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
if (this.printService) {
// There is no way to suppress beforePrint/afterPrint events,
// but PDFPrintService may generate double events -- this will ignore
// the second event that will be coming from native window.print().
return;
}
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
if (!this.supportsPrinting) {
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-02-22 20:43:16 +09:00
this.l10n.get("printing_not_supported").then(msg => {
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-10 23:57:58 +09:00
this._otherError(msg);
});
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
return;
}
Changes to viewer to support progressive loading
2013-03-09 11:08:37 +09:00
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
// The beforePrint is a sync method and we need to know layout before
// returning from this method. Ensure that we can get sizes of the pages.
if (!this.pdfViewer.pageViewsReady) {
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-02-22 20:43:16 +09:00
this.l10n.get("printing_not_ready").then(msg => {
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-10 23:57:58 +09:00
// eslint-disable-next-line no-alert
window.alert(msg);
});
Changes to viewer to support progressive loading
2013-03-09 11:08:37 +09:00
return;
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const pagesOverview = this.pdfViewer.getPagesOverview();
const printContainer = this.appConfig.printContainer;
Do the `AppOptions.get("printResolution")` lookup once in `web/app.js`, when initializing `PDFPrintServiceFactory`-instances, rather than for every printed page There's really no point in repeating these lookups over and over, since the value should be constant for the duration of one print invocation anyway.
2020-08-05 20:24:32 +09:00
const printResolution = AppOptions.get("printResolution");
Account for formatting changes in Prettier version `2.3.0` With the exception of one tweaked `eslint-disable` comment, in `web/generic_scripting.js`, this patch was generated automatically using `gulp lint --fix`. Please find additional information at: - https://github.com/prettier/prettier/releases/tag/2.3.0 - https://prettier.io/blog/2021/05/09/2.3.0.html
2021-05-16 17:58:34 +09:00
const optionalContentConfigPromise =
this.pdfViewer.optionalContentConfigPromise;
Do the `AppOptions.get("printResolution")` lookup once in `web/app.js`, when initializing `PDFPrintServiceFactory`-instances, rather than for every printed page There's really no point in repeating these lookups over and over, since the value should be constant for the duration of one print invocation anyway.
2020-08-05 20:24:32 +09:00
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const printService = PDFPrintServiceFactory.instance.createPrintService(
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.pdfDocument,
pagesOverview,
printContainer,
Do the `AppOptions.get("printResolution")` lookup once in `web/app.js`, when initializing `PDFPrintServiceFactory`-instances, rather than for every printed page There's really no point in repeating these lookups over and over, since the value should be constant for the duration of one print invocation anyway.
2020-08-05 20:24:32 +09:00
printResolution,
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
optionalContentConfigPromise,
[api-minor] Introduce a `PrintAnnotationStorage` with *frozen* serializable data Given that printing is triggered *synchronously* in browsers, it's thus possible for scripting (in PDF documents) to modify the Annotation-data while printing is currently ongoing. To work-around that we add a new printing-specific `AnnotationStorage`, where the serializable data is *frozen* upon initialization, which the viewer can thus create/utilize during printing.
2022-06-13 20:35:58 +09:00
this._printAnnotationStoragePromise,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.l10n
);
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
this.printService = printService;
Moves rendering queue logic from PDFView
2014-09-16 01:18:28 +09:00
this.forceRendering();
Disable the editing-indicator, in the document title, during printing (bug 1790552, PR 15351 follow-up)
2022-09-13 17:57:10 +09:00
// Disable the editor-indicator during printing (fixes bug 1790552).
this.setTitle();
Do not run cleanup while printing is ongoing.
2014-06-25 07:23:42 +09:00
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
printService.layout();
Reporting print usage
2014-06-15 05:55:21 +09:00
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
if (this._hasAnnotationEditors) {
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
this.externalServices.reportTelemetry({
type: "editing",
[api-minor][editor] Indicate, in the title, if the document has been edited (bug 1785854) Note that this patch prepends the document title with "* ", rather than only "*" as suggested in the bug, since there's nothing that says that a PDF document cannot specify a title[1] beginning with an asterisk. To reduce possible confusion, having a space between the "editing marker" and the actual document title thus cannot hurt as far as I'm concerned. In order to notify the viewer when all `AnnotationEditor`s have been removed, we utilize the existing `onAnnotationEditor`-callback to allow the document title to be updated as necessary. Finally, this patch makes the following (slightly unrelated) changes: - Rename the `AnnotationStorage.removeKey` method to just `AnnotationStorage.remove` instead. This is consistent with e.g. the `has`-method and should suffice to explain what it does. - Remove the `AnnotationStorage.hasAnnotationEditors` getter, since the viewer now tracks the necessary state internally. This avoids unnecessarily having to iterate through the `AnnotationStorage`-instance when saving/printing the document. --- [1] Using either an /Info dictionary or a /Metadata stream.
2022-08-26 07:03:19 +09:00
data: { type: "print" },
[Editor] Add some telemetry to know how often the editing features are used (bug 1782254)
2022-08-03 01:29:01 +09:00
});
}
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
},
Use shorthand method signature for `afterPrint` in `web/app.js`
2019-08-24 18:48:33 +09:00
afterPrint() {
[api-minor] Introduce a `PrintAnnotationStorage` with *frozen* serializable data Given that printing is triggered *synchronously* in browsers, it's thus possible for scripting (in PDF documents) to modify the Annotation-data while printing is currently ongoing. To work-around that we add a new printing-specific `AnnotationStorage`, where the serializable data is *frozen* upon initialization, which the viewer can thus create/utilize during printing.
2022-06-13 20:35:58 +09:00
if (this._printAnnotationStoragePromise) {
this._printAnnotationStoragePromise.then(() => {
this.pdfScriptingManager.dispatchDidPrint();
});
this._printAnnotationStoragePromise = null;
}
[Scripting] Try to ensure that the `WillPrint`/`DidPrint` respectively `DidSave` events are always dispatched Note that currently the `DidSave` event is not *guaranteed* to actually be dispatched if there's any errors during saving, which is easily fixed by simply moving it to occur in the `finally`-handler in `PDFViewerApplication.save` method. For the `WillPrint`/`DidPrint` events, things are unfortunately more complicated. Currently these events will *only* be dispatched iff the printing request comes from within the viewer itself (e.g. by the user clicking on the "Print" toolbar button), however printing can be triggered in a few additional ways: - In the GENERIC viewer: - By the <kbd>Ctrl</kbd>+<kbd>P</kbd> keyboard shortcut. - In the MOZCENTRAL viewer, i.e. the Firefox built-in viewer: - By the <kbd>Ctrl</kbd>+<kbd>P</kbd> keyboard shortcut. - By the "Print" item, as found in either the Firefox "Hamburger menu" or in the browser-window menu. In either of the cases described above, no `WillPrint`/`DidPrint` events will be dispatched. In order to *guarantee* that things work in the general case, we thus have to move the `dispatchEventInSandbox` calls to the "beforeprint"/"afterprint" event handlers instead.
2020-12-23 19:13:43 +09:00
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
if (this.printService) {
this.printService.destroy();
this.printService = null;
Don't warn when navigating away from a modified form, if printing has occurred (issue 12262) This solution is obviously *not* perfect, since printing being cancelled will thus remove the warning as well. However, a similar problem already exists for saving, since the user may cancel that one as well. All-in-all, since way cannot really detect with absolute certainty that either saving or printing actually finished, this seems good enough for now.
2020-08-23 00:37:26 +09:00
Use optional chaining even more in the `web/app.js` file
2021-08-28 00:29:00 +09:00
this.pdfDocument?.annotationStorage.resetModified();
Fix coding style in web/viewer.js
2014-03-09 20:20:32 +09:00
}
Moves rendering queue logic from PDFView
2014-09-16 01:18:28 +09:00
this.forceRendering();
Disable the editing-indicator, in the document title, during printing (bug 1790552, PR 15351 follow-up)
2022-09-13 17:57:10 +09:00
// Re-enable the editor-indicator after printing (fixes bug 1790552).
this.setTitle();
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
},
Reset `pageRotation` and `downloadComplete` in `PDFViewerApplication.close` Currently, these properties are reset in what appears to be somewhat arbitrary locations (within the `load` and `open` methods respectively). The explanation is probably that both of these properties predates the existence of any centralized clean-up code in the viewer. Hence I think that it makes sense to move the resetting of these properties to the `close` method, since that improves the overview of what's actually cleaned-up/reset when changing documents in the viewer.
2017-06-17 20:14:36 +09:00
rotatePages(delta) {
Move rotation normalization from `PDFViewerApplication` and into `BaseViewer` The rotation handling that's currently living in `PDFViewerApplication` is *very* old, and pre-dates the introduction of the viewer components by years. As can be seen in the `BaseViewer.pagesRotation` setter, we're not actually normalizing the rotation as intended and instead rely on the caller to handle that correctly. This is first of all inconsistent, given how other setters are implemented, and secondly it could also lead to the rotation being set to a value outside of the `[0, 360)`-range. Finally, for improved consistency the rotation handling in `PageViewport` is updated similarly. Please note that this case, it's *not* changing the pre-existing logic.
2021-03-28 21:12:13 +09:00
this.pdfViewer.pagesRotation += delta;
Slightly refactor the pages rotation handling code in the viewer This changes both `PDFViewer` and `PDFThumbnailViewer` to return early in the `pagesRotation` setters if the rotation doesn't change. It also fixes an existing issue, in `PDFViewer`, that would cause errors if the rotation changes *before* the scale has been set to a non-default value. Finally, in preparation for subsequent patches, it also refactors the rotation code in `web/app.js` to update the thumbnails and trigger rendering with the new `rotationchanging` event.
2017-08-19 21:23:40 +09:00
// Note that the thumbnail viewer is updated, and rendering is triggered,
// in the 'rotationchanging' event handler.
Add firefox mouse scrolling support in presentation mode. Convert ticks to mouse delta values and use that to determine when to flip the page. Also use cooldown time for presentation mode page scrolling. This way hi res mouses do not scroll multiple pages at once. http://www.codeproject.com/Articles/155717/Handling-Enhanced-Mouse-Wheels-in-your-Application
2012-09-14 05:23:44 +09:00
},
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
requestPresentationMode() {
Use optional chaining even more in the `web/app.js` file
2021-08-28 00:29:00 +09:00
this.pdfPresentationMode?.request();
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
},
Re-factor how printing is triggered in the default viewer This adds a new `PDFViewerApplication.triggerPrinting` method, which takes care of checking that printing is actually supported before calling `window.print`, to remove the need to duplicate that code in multiple places. Also, removes the `PDFViewerApplication.printing` getter since it's not really necessary any more.
2020-09-30 22:02:11 +09:00
triggerPrinting() {
if (!this.supportsPrinting) {
return;
}
Revert "Don't use window.print in the Firefox builtin viewer (bug 1774427)"
2022-09-22 23:58:49 +09:00
window.print();
Re-factor how printing is triggered in the default viewer This adds a new `PDFViewerApplication.triggerPrinting` method, which takes care of checking that printing is actually supported before calling `window.print`, to remove the need to duplicate that code in multiple places. Also, removes the `PDFViewerApplication.printing` getter since it's not really necessary any more.
2020-09-30 22:02:11 +09:00
},
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
bindEvents() {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const { eventBus, _boundEvents } = this;
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.beforePrint = this.beforePrint.bind(this);
_boundEvents.afterPrint = this.afterPrint.bind(this);
Adds EventBus.
2016-04-26 07:57:15 +09:00
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._on("resize", webViewerResize);
eventBus._on("hashchange", webViewerHashchange);
eventBus._on("beforeprint", _boundEvents.beforePrint);
eventBus._on("afterprint", _boundEvents.afterPrint);
Only display the pageNumber-loadingIcon when rendering is currently running *This makes the same kind of changes as in the previous patch, but for the pageNumber-loadingIcon in the main toolbar.* To display the pageNumber-loadingIcon when rendering starts, if the page is the most visible one, we'll utilize the existing "pagerender" event. To toggle the pageNumber-loadingIcon as the user moves through the document we'll now instead utilize the "pagechanging" event, which should actually be slightly more efficient overall[1]. Note how we'd, in the old code, only consider the most visible page anyway when toggling the pageNumber-loadingIcon. --- [1] Even in a PDF document as relatively short/simple as `tracemonkey.pdf`, scrolling through the entire document can easily trigger the "updateviewarea" event more than a thousand times.
2022-12-26 23:00:30 +09:00
eventBus._on("pagerender", webViewerPageRender);
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._on("pagerendered", webViewerPageRendered);
eventBus._on("updateviewarea", webViewerUpdateViewarea);
eventBus._on("pagechanging", webViewerPageChanging);
eventBus._on("scalechanging", webViewerScaleChanging);
eventBus._on("rotationchanging", webViewerRotationChanging);
eventBus._on("sidebarviewchanged", webViewerSidebarViewChanged);
eventBus._on("pagemode", webViewerPageMode);
eventBus._on("namedaction", webViewerNamedAction);
eventBus._on("presentationmodechanged", webViewerPresentationModeChanged);
eventBus._on("presentationmode", webViewerPresentationMode);
[edition] Add a FreeText editor (#14970) - add a basic UI to edit some text in a pdf; - an editor can be moved, suppressed, cut, copied, pasted, selected; - add an undo/redo manager.
2022-06-01 17:38:08 +09:00
eventBus._on(
"switchannotationeditormode",
webViewerSwitchAnnotationEditorMode
);
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
eventBus._on(
"switchannotationeditorparams",
webViewerSwitchAnnotationEditorParams
);
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._on("print", webViewerPrint);
eventBus._on("download", webViewerDownload);
eventBus._on("firstpage", webViewerFirstPage);
eventBus._on("lastpage", webViewerLastPage);
eventBus._on("nextpage", webViewerNextPage);
eventBus._on("previouspage", webViewerPreviousPage);
eventBus._on("zoomin", webViewerZoomIn);
eventBus._on("zoomout", webViewerZoomOut);
eventBus._on("zoomreset", webViewerZoomReset);
eventBus._on("pagenumberchanged", webViewerPageNumberChanged);
eventBus._on("scalechanged", webViewerScaleChanged);
eventBus._on("rotatecw", webViewerRotateCw);
eventBus._on("rotateccw", webViewerRotateCcw);
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
eventBus._on("optionalcontentconfig", webViewerOptionalContentConfig);
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._on("switchscrollmode", webViewerSwitchScrollMode);
eventBus._on("scrollmodechanged", webViewerScrollModeChanged);
eventBus._on("switchspreadmode", webViewerSwitchSpreadMode);
eventBus._on("spreadmodechanged", webViewerSpreadModeChanged);
eventBus._on("documentproperties", webViewerDocumentProperties);
eventBus._on("findfromurlhash", webViewerFindFromUrlHash);
eventBus._on("updatefindmatchescount", webViewerUpdateFindMatchesCount);
eventBus._on("updatefindcontrolstate", webViewerUpdateFindControlState);
Remove the `PDFPageView.stats` property, and fetch it manually only when debugging is enabled Given that the default viewer only uses the "page stats" when debugging is enabled, it seems much simpler and more straightforward to simply query the API *directly* when this information is actually required. That way, there's a bit less information that needs to be stored/updated on each `PDFPageView`-instance. Finally, since the `EventBus` now exists, we no longer need to handle the "page stats"-case in the regular listeners in `web/app.js`, but can instead add special "page stats"-listeners only when debugging is enabled.
2020-09-23 21:39:14 +09:00
if (AppOptions.get("pdfBug")) {
_boundEvents.reportPageStatsPDFBug = reportPageStatsPDFBug;
eventBus._on("pagerendered", _boundEvents.reportPageStatsPDFBug);
eventBus._on("pagechanging", _boundEvents.reportPageStatsPDFBug);
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._on("fileinputchange", webViewerFileInputChange);
Move the `webViewerOpenFile` function, and the "openfile" eventBus listener, since they only matter in GENERIC builds of the default viewer This is similar to the existing implementation of the `webViewerFileInputChange` function and its associated "fileinputchange" event.
2020-03-17 21:26:35 +09:00
eventBus._on("openfile", webViewerOpenFile);
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
[Editor] Dispatch an event when some global states are changing - this way the context menu in Firefox can take into account what we have in the clipboard, if an editor is selected, ... - when the user will click on a context menu item, an action will be triggered, hence this patch adds what is required to handle it; - some tests will be added in the Firefox' patch.
2022-07-05 01:04:32 +09:00
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("MOZCENTRAL")) {
eventBus._on(
"annotationeditorstateschanged",
webViewerAnnotationEditorStatesChanged
);
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
},
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
bindWindowEvents() {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const { eventBus, _boundEvents } = this;
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
Refresh the viewer if the window resolution changes (bug 1784850) *Please note:* This probably fixes bug 1784850, however I don't have the necessary hardware to reproduce the situation described in https://bugzilla.mozilla.org/show_bug.cgi?id=1784850#c0 Unfortunately it doesn't, as far as I can tell, appear possible to detect *all* resolution changes with a single media query. Instead we have to update it, and its listener, on every resolution change as outlined in [this MDN example](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio#monitoring_screen_resolution_or_zoom_level_changes).
2022-08-15 23:21:58 +09:00
function addWindowResolutionChange(evt = null) {
if (evt) {
webViewerResolutionChange(evt);
}
const mediaQueryList = window.matchMedia(
`(resolution: ${window.devicePixelRatio || 1}dppx)`
);
mediaQueryList.addEventListener("change", addWindowResolutionChange, {
once: true,
});
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("MOZCENTRAL")) {
return;
}
_boundEvents.removeWindowResolutionChange ||= function () {
mediaQueryList.removeEventListener("change", addWindowResolutionChange);
_boundEvents.removeWindowResolutionChange = null;
};
}
addWindowResolutionChange();
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.windowResize = () => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
eventBus.dispatch("resize", { source: window });
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
};
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.windowHashChange = () => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
eventBus.dispatch("hashchange", {
Add `source` parameters to all remaining `EventBus.dispatch` calls that are currently missing those This is necessary for subsequent patches, and will help avoid unnecessary event re-dispatching in cases where the event source is `window`.
2018-08-28 16:56:26 +09:00
source: window,
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
hash: document.location.hash.substring(1),
});
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
};
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.windowBeforePrint = () => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
eventBus.dispatch("beforeprint", { source: window });
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
};
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.windowAfterPrint = () => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
eventBus.dispatch("afterprint", { source: window });
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
};
Update the events, used with scripting, to use lower-case names and avoid using DOM events internally in the viewer For DOM events all event names are lower-case, and the newly added PDF.js scripting-events thus "stick out" quite a bit. Even more so, considering that our internal `eventBus`-events follow the same naming convention. Hence this patch, which changes the "updateFromSandbox"/"dispatchEventInSandbox" events to be lower-case instead. Furthermore, using DOM events for communication *within* the PDF.js code itself (i.e. between code in `web/app.js` and `src/display/annotation_layer.js/`) feels *really* out of place. That's exactly the reason that we have the `EventBus` abstraction, since it allowed us to remove prior use of DOM events, and this patch thus re-factors the code to make use of the `EventBus` instead for scripting-related events. Obviously for events targeting a *specific element* using DOM events is still fine, but the "updatefromsandbox"/"dispatcheventinsandbox" ones should be using the `EventBus` internally. *Drive-by change:* Use the `BaseViewer.currentScaleValue` setter unconditionally in `PDFViewerApplication._initializeJavaScript`, since it accepts either a string or a number.
2020-12-17 22:10:56 +09:00
_boundEvents.windowUpdateFromSandbox = event => {
eventBus.dispatch("updatefromsandbox", {
source: window,
detail: event.detail,
});
};
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.addEventListener("visibilitychange", webViewerVisibilityChange);
window.addEventListener("wheel", webViewerWheel, { passive: false });
Bug 1643508 - Disable touch-based pinch zooming on pdf.js. Currently using a touchscreen with pdf.js doesn't work so well. In Firefox, with apz.allow_zooming = false (default on current release/beta), it does a reflow zoom which makes the UI elements bigger. And with apz.allow_zooming = true (default on current Firefox nightly), or in Chrome, it does a smooth pinch-zoom but that also scales up the entire UI. Neither of these is a particularly good experience, so this patch just disables any multi-touch gestures. Touch-based panning (which involves a single touch point) is left unaffected.
2020-08-13 04:09:42 +09:00
window.addEventListener("touchstart", webViewerTouchStart, {
passive: false,
});
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
window.addEventListener("touchmove", webViewerTouchMove, {
passive: false,
});
window.addEventListener("touchend", webViewerTouchEnd, {
passive: false,
});
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.addEventListener("click", webViewerClick);
window.addEventListener("keydown", webViewerKeyDown);
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
window.addEventListener("keyup", webViewerKeyUp);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.addEventListener("resize", _boundEvents.windowResize);
window.addEventListener("hashchange", _boundEvents.windowHashChange);
window.addEventListener("beforeprint", _boundEvents.windowBeforePrint);
window.addEventListener("afterprint", _boundEvents.windowAfterPrint);
Update the events, used with scripting, to use lower-case names and avoid using DOM events internally in the viewer For DOM events all event names are lower-case, and the newly added PDF.js scripting-events thus "stick out" quite a bit. Even more so, considering that our internal `eventBus`-events follow the same naming convention. Hence this patch, which changes the "updateFromSandbox"/"dispatchEventInSandbox" events to be lower-case instead. Furthermore, using DOM events for communication *within* the PDF.js code itself (i.e. between code in `web/app.js` and `src/display/annotation_layer.js/`) feels *really* out of place. That's exactly the reason that we have the `EventBus` abstraction, since it allowed us to remove prior use of DOM events, and this patch thus re-factors the code to make use of the `EventBus` instead for scripting-related events. Obviously for events targeting a *specific element* using DOM events is still fine, but the "updatefromsandbox"/"dispatcheventinsandbox" ones should be using the `EventBus` internally. *Drive-by change:* Use the `BaseViewer.currentScaleValue` setter unconditionally in `PDFViewerApplication._initializeJavaScript`, since it accepts either a string or a number.
2020-12-17 22:10:56 +09:00
window.addEventListener(
"updatefromsandbox",
_boundEvents.windowUpdateFromSandbox
);
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
},
unbindEvents() {
Stop bundling `PDFViewerApplication.{unbindEvents, unbindWindowEvents}` in MOZCENTRAL builds These methods are completely unused in the Firefox PDF Viewer, and were only added to supplement the `PDFViewerApplication.{bindEvents, bindWindowEvents}`-methods since third-party implementations may apparently need to remove event listeners (see PR 8525). However, in the MOZCENTRAL build that's just dead code and this patch reduces the size of the *built* `web/viewer.js`-file by `~3.5` kB.
2022-05-07 22:48:54 +09:00
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("MOZCENTRAL")) {
throw new Error("Not implemented: unbindEvents");
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const { eventBus, _boundEvents } = this;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._off("resize", webViewerResize);
eventBus._off("hashchange", webViewerHashchange);
eventBus._off("beforeprint", _boundEvents.beforePrint);
eventBus._off("afterprint", _boundEvents.afterPrint);
Only display the pageNumber-loadingIcon when rendering is currently running *This makes the same kind of changes as in the previous patch, but for the pageNumber-loadingIcon in the main toolbar.* To display the pageNumber-loadingIcon when rendering starts, if the page is the most visible one, we'll utilize the existing "pagerender" event. To toggle the pageNumber-loadingIcon as the user moves through the document we'll now instead utilize the "pagechanging" event, which should actually be slightly more efficient overall[1]. Note how we'd, in the old code, only consider the most visible page anyway when toggling the pageNumber-loadingIcon. --- [1] Even in a PDF document as relatively short/simple as `tracemonkey.pdf`, scrolling through the entire document can easily trigger the "updateviewarea" event more than a thousand times.
2022-12-26 23:00:30 +09:00
eventBus._off("pagerender", webViewerPageRender);
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._off("pagerendered", webViewerPageRendered);
eventBus._off("updateviewarea", webViewerUpdateViewarea);
eventBus._off("pagechanging", webViewerPageChanging);
eventBus._off("scalechanging", webViewerScaleChanging);
eventBus._off("rotationchanging", webViewerRotationChanging);
eventBus._off("sidebarviewchanged", webViewerSidebarViewChanged);
eventBus._off("pagemode", webViewerPageMode);
eventBus._off("namedaction", webViewerNamedAction);
eventBus._off("presentationmodechanged", webViewerPresentationModeChanged);
eventBus._off("presentationmode", webViewerPresentationMode);
eventBus._off("print", webViewerPrint);
eventBus._off("download", webViewerDownload);
eventBus._off("firstpage", webViewerFirstPage);
eventBus._off("lastpage", webViewerLastPage);
eventBus._off("nextpage", webViewerNextPage);
eventBus._off("previouspage", webViewerPreviousPage);
eventBus._off("zoomin", webViewerZoomIn);
eventBus._off("zoomout", webViewerZoomOut);
eventBus._off("zoomreset", webViewerZoomReset);
eventBus._off("pagenumberchanged", webViewerPageNumberChanged);
eventBus._off("scalechanged", webViewerScaleChanged);
eventBus._off("rotatecw", webViewerRotateCw);
eventBus._off("rotateccw", webViewerRotateCcw);
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
eventBus._off("optionalcontentconfig", webViewerOptionalContentConfig);
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._off("switchscrollmode", webViewerSwitchScrollMode);
eventBus._off("scrollmodechanged", webViewerScrollModeChanged);
eventBus._off("switchspreadmode", webViewerSwitchSpreadMode);
eventBus._off("spreadmodechanged", webViewerSpreadModeChanged);
eventBus._off("documentproperties", webViewerDocumentProperties);
eventBus._off("findfromurlhash", webViewerFindFromUrlHash);
eventBus._off("updatefindmatchescount", webViewerUpdateFindMatchesCount);
eventBus._off("updatefindcontrolstate", webViewerUpdateFindControlState);
Remove the `PDFPageView.stats` property, and fetch it manually only when debugging is enabled Given that the default viewer only uses the "page stats" when debugging is enabled, it seems much simpler and more straightforward to simply query the API *directly* when this information is actually required. That way, there's a bit less information that needs to be stored/updated on each `PDFPageView`-instance. Finally, since the `EventBus` now exists, we no longer need to handle the "page stats"-case in the regular listeners in `web/app.js`, but can instead add special "page stats"-listeners only when debugging is enabled.
2020-09-23 21:39:14 +09:00
if (_boundEvents.reportPageStatsPDFBug) {
eventBus._off("pagerendered", _boundEvents.reportPageStatsPDFBug);
eventBus._off("pagechanging", _boundEvents.reportPageStatsPDFBug);
_boundEvents.reportPageStatsPDFBug = null;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
Re-factor the `EventBus` to allow servicing of "external" event listeners *after* the viewer components have updated Since the goal has always been, essentially since the `EventBus` abstraction was added, to remove all dispatching of DOM events[1] from the viewer components this patch tries to address one thing that came up when updating the examples: The DOM events are always dispatched last, and it's thus guaranteed that all internal event listeners have been invoked first. However, there's no such guarantees with the general `EventBus` functionality and the order in which event listeners are invoked is *not* specified. With the promotion of the `EventBus` in the examples, over DOM events, it seems like a good idea to at least *try* to keep this ordering invariant[2] intact. Obviously this won't prevent anyone from manually calling the new *internal* viewer component methods on the `EventBus`, but hopefully that won't be too common since any existing third-party code would obviously use the `on`/`off` methods and that all of the examples shows the *correct* usage (which should be similarily documented on the "Third party viewer usage" Wiki-page). --- [1] Looking at the various Firefox-tests, I'm not sure that it'll be possible to (easily) re-write all of them to not rely on DOM events (since getting access to `PDFViewerApplication` might be generally difficult/messy depending on scopes). In any case, even if technically feasible, it would most likely add *a lot* of complication that may not be desireable in the various Firefox-tests. All-in-all, I'd be fine with keeping the DOM events only for the `MOZCENTRAL` target and gated on `Cu.isInAutomation` (or similar) rather than a preference. [2] I wouldn't expect any *real* bugs in a custom implementation, simply based on event ordering, but it nonetheless seem like a good idea if any "external" events are still handled last.
2020-02-27 07:33:27 +09:00
eventBus._off("fileinputchange", webViewerFileInputChange);
Move the `webViewerOpenFile` function, and the "openfile" eventBus listener, since they only matter in GENERIC builds of the default viewer This is similar to the existing implementation of the `webViewerFileInputChange` function and its associated "fileinputchange" event.
2020-03-17 21:26:35 +09:00
eventBus._off("openfile", webViewerOpenFile);
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
}
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.beforePrint = null;
_boundEvents.afterPrint = null;
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
},
unbindWindowEvents() {
Stop bundling `PDFViewerApplication.{unbindEvents, unbindWindowEvents}` in MOZCENTRAL builds These methods are completely unused in the Firefox PDF Viewer, and were only added to supplement the `PDFViewerApplication.{bindEvents, bindWindowEvents}`-methods since third-party implementations may apparently need to remove event listeners (see PR 8525). However, in the MOZCENTRAL build that's just dead code and this patch reduces the size of the *built* `web/viewer.js`-file by `~3.5` kB.
2022-05-07 22:48:54 +09:00
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("MOZCENTRAL")) {
throw new Error("Not implemented: unbindWindowEvents");
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const { _boundEvents } = this;
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.removeEventListener("visibilitychange", webViewerVisibilityChange);
Add `passive: false` when removing wheel listeners Code of listening `wheel` event uses `{passive: false}`, while this argument will be treated as `true` before Firefox 49, accordin to https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#Browser_compatibility . This commit adds it when removing wheel listeners, so that such listeners can be really removed.
2020-03-25 22:53:08 +09:00
window.removeEventListener("wheel", webViewerWheel, { passive: false });
Bug 1643508 - Disable touch-based pinch zooming on pdf.js. Currently using a touchscreen with pdf.js doesn't work so well. In Firefox, with apz.allow_zooming = false (default on current release/beta), it does a reflow zoom which makes the UI elements bigger. And with apz.allow_zooming = true (default on current Firefox nightly), or in Chrome, it does a smooth pinch-zoom but that also scales up the entire UI. Neither of these is a particularly good experience, so this patch just disables any multi-touch gestures. Touch-based panning (which involves a single touch point) is left unaffected.
2020-08-13 04:09:42 +09:00
window.removeEventListener("touchstart", webViewerTouchStart, {
passive: false,
});
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
window.removeEventListener("touchmove", webViewerTouchMove, {
passive: false,
});
window.removeEventListener("touchend", webViewerTouchEnd, {
passive: false,
});
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.removeEventListener("click", webViewerClick);
window.removeEventListener("keydown", webViewerKeyDown);
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
window.removeEventListener("keyup", webViewerKeyUp);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
window.removeEventListener("resize", _boundEvents.windowResize);
window.removeEventListener("hashchange", _boundEvents.windowHashChange);
window.removeEventListener("beforeprint", _boundEvents.windowBeforePrint);
window.removeEventListener("afterprint", _boundEvents.windowAfterPrint);
Update the events, used with scripting, to use lower-case names and avoid using DOM events internally in the viewer For DOM events all event names are lower-case, and the newly added PDF.js scripting-events thus "stick out" quite a bit. Even more so, considering that our internal `eventBus`-events follow the same naming convention. Hence this patch, which changes the "updateFromSandbox"/"dispatchEventInSandbox" events to be lower-case instead. Furthermore, using DOM events for communication *within* the PDF.js code itself (i.e. between code in `web/app.js` and `src/display/annotation_layer.js/`) feels *really* out of place. That's exactly the reason that we have the `EventBus` abstraction, since it allowed us to remove prior use of DOM events, and this patch thus re-factors the code to make use of the `EventBus` instead for scripting-related events. Obviously for events targeting a *specific element* using DOM events is still fine, but the "updatefromsandbox"/"dispatcheventinsandbox" ones should be using the `EventBus` internally. *Drive-by change:* Use the `BaseViewer.currentScaleValue` setter unconditionally in `PDFViewerApplication._initializeJavaScript`, since it accepts either a string or a number.
2020-12-17 22:10:56 +09:00
window.removeEventListener(
"updatefromsandbox",
_boundEvents.windowUpdateFromSandbox
);
Allow for unbinding of events in web application Hold bound event listeners for later unbinding ES6 styling More ES6 styling and code cleanup Remove 4 space indents and remove delete statements.
2017-06-14 04:11:29 +09:00
Refresh the viewer if the window resolution changes (bug 1784850) *Please note:* This probably fixes bug 1784850, however I don't have the necessary hardware to reproduce the situation described in https://bugzilla.mozilla.org/show_bug.cgi?id=1784850#c0 Unfortunately it doesn't, as far as I can tell, appear possible to detect *all* resolution changes with a single media query. Instead we have to update it, and its listener, on every resolution change as outlined in [this MDN example](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio#monitoring_screen_resolution_or_zoom_level_changes).
2022-08-15 23:21:58 +09:00
_boundEvents.removeWindowResolutionChange?.();
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
_boundEvents.windowResize = null;
_boundEvents.windowHashChange = null;
_boundEvents.windowBeforePrint = null;
_boundEvents.windowAfterPrint = null;
Update the events, used with scripting, to use lower-case names and avoid using DOM events internally in the viewer For DOM events all event names are lower-case, and the newly added PDF.js scripting-events thus "stick out" quite a bit. Even more so, considering that our internal `eventBus`-events follow the same naming convention. Hence this patch, which changes the "updateFromSandbox"/"dispatchEventInSandbox" events to be lower-case instead. Furthermore, using DOM events for communication *within* the PDF.js code itself (i.e. between code in `web/app.js` and `src/display/annotation_layer.js/`) feels *really* out of place. That's exactly the reason that we have the `EventBus` abstraction, since it allowed us to remove prior use of DOM events, and this patch thus re-factors the code to make use of the `EventBus` instead for scripting-related events. Obviously for events targeting a *specific element* using DOM events is still fine, but the "updatefromsandbox"/"dispatcheventinsandbox" ones should be using the `EventBus` internally. *Drive-by change:* Use the `BaseViewer.currentScaleValue` setter unconditionally in `PDFViewerApplication._initializeJavaScript`, since it accepts either a string or a number.
2020-12-17 22:10:56 +09:00
_boundEvents.windowUpdateFromSandbox = null;
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
},
Bug 1392361 - Fix zooming sensitivity on macOS The original code would get a long sequence of miniscule "tick" values while pinch-zooming, and each tick value would cause a 1.1x zoom. So even the smallest pinch gesture on a trackpad would cause high amounts of zoom. This patch accumulates the wheel deltas until they reach an integer threshold (with a tweak of the scaling factor to make it feel more natural) at which point it triggers the zoom based on the integer component of the accumulated delta. The fractional part is retained in the accumulator.
2020-08-13 03:30:45 +09:00
Reduce duplication in the `accumulateWheelTicks`/`accumulateTouchTicks` methods (PR 15886 follow-up) It just occurred to me that we can reduce some duplication by having the, virtually identical, `accumulateWheelTicks`/`accumulateTouchTicks` methods use a common helper instead that takes advantage of [bracket notation](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics#bracket_notation).
2023-01-05 01:32:18 +09:00
_accumulateTicks(ticks, prop) {
// If the direction changed, reset the accumulated ticks.
if ((this[prop] > 0 && ticks < 0) || (this[prop] < 0 && ticks > 0)) {
this[prop] = 0;
}
this[prop] += ticks;
const wholeTicks = Math.trunc(this[prop]);
this[prop] -= wholeTicks;
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
return wholeTicks;
},
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
_accumulateFactor(previousScale, factor, prop) {
if (factor === 1) {
return 1;
}
// If the direction changed, reset the accumulated factor.
if ((this[prop] > 1 && factor < 1) || (this[prop] < 1 && factor > 1)) {
this[prop] = 1;
}
const newFactor =
Math.floor(previousScale * factor * this[prop] * 100) /
(100 * previousScale);
this[prop] = factor / newFactor;
return newFactor;
},
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
_centerAtPos(previousScale, x, y) {
const { pdfViewer } = this;
const scaleDiff = pdfViewer.currentScale / previousScale - 1;
if (scaleDiff !== 0) {
const [top, left] = pdfViewer.containerTopLeft;
pdfViewer.container.scrollLeft += (x - left) * scaleDiff;
pdfViewer.container.scrollTop += (y - top) * scaleDiff;
}
},
[Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553)
2021-02-06 06:00:10 +09:00
/**
* Should be called *after* all pages have loaded, or if an error occurred,
* to unblock the "load" event; see https://bugzilla.mozilla.org/show_bug.cgi?id=1618553
* @private
*/
_unblockDocumentLoadEvent() {
Use a bit more optional chaining in the viewer
2022-04-07 23:20:41 +09:00
document.blockUnblockOnload?.(false);
[Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553)
2021-02-06 06:00:10 +09:00
// Ensure that this method is only ever run once.
this._unblockDocumentLoadEvent = () => {};
},
Remove the arbitrary timeout in the "must check that first text field has focus" integration-test (PR 12702 follow-up) It seems that the timeout is way too short in practice, since this new integration-test failed *intermittently* already in PR 12702 (which is where the test was added). The ideal solution here would be to simply await an event, dispatched by the viewer, however that unfortunately doesn't appear to be supported by Puppeteer. Instead, the solution implemented here is to add a new method in `PDFViewerApplication` which Puppeteer can query to check if the scripting/sandbox has been fully initialized.
2020-12-19 07:12:52 +09:00
/**
* Used together with the integration-tests, to enable awaiting full
* initialization of the scripting/sandbox.
*/
get scriptingReady() {
[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 08:15:18 +09:00
return this.pdfScriptingManager.ready;
Remove the arbitrary timeout in the "must check that first text field has focus" integration-test (PR 12702 follow-up) It seems that the timeout is way too short in practice, since this new integration-test failed *intermittently* already in PR 12702 (which is where the test was added). The ideal solution here would be to simply await an event, dispatched by the viewer, however that unfortunately doesn't appear to be supported by Puppeteer. Instead, the solution implemented here is to add a new method in `PDFViewerApplication` which Puppeteer can query to check if the scripting/sandbox has been fully initialized.
2020-12-19 07:12:52 +09:00
},
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
};
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
const HOSTED_VIEWER_ORIGINS = [
"null",
"http://mozilla.github.io",
"https://mozilla.github.io",
];
Only define the `validateFileURL` variable in GENERIC builds There's no point in having this variable defined (implicitly) as `undefined` in e.g. the Firefox PDF Viewer. By defining it with `var` and using an ESLint ignore, rather than `let`, we can move it into the relevant pre-processor block instead. Note that since the entire viewer-code is placed, by Webpack, in a top-level closure this variable will thus not become globally accessible.
2022-09-13 21:07:17 +09:00
// eslint-disable-next-line no-var
var validateFileURL = function (file) {
[GENERIC viewer] Remove some, now unnecessary, checks used with `fileInput` According to the MDN compatibility data, see below, all of these features have been supported for years and years in all browsers. Looking closely at the data, the most likely reason for adding these checks in the first place was for IE 9 compatibility (since we originally "supported" that browser). - https://developer.mozilla.org/en-US/docs/Web/API/File#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/FileReader#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/FileList#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/Blob#browser_compatibility
2022-04-10 19:50:35 +09:00
if (!file) {
Check for undefined url (#8640) * Check for undefined new URL(file, window.location.href) throws the following error in IE11 + iPad Safari: Unable to get property 'replace' of undefined or null reference * Adapting previous change to pdf.js code standards Added curly braces * Moved check for undefined above try/catch
2017-07-14 05:48:04 +09:00
return;
}
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
try {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const viewerOrigin = new URL(window.location.href).origin || "null";
Enable the `mozilla/use-includes-instead-of-indexOf` ESLint rule globally This rule is available from https://www.npmjs.com/package/eslint-plugin-mozilla, and is enforced in mozilla-central. Note that we have the necessary `Array`/`String` polyfills and that most cases have already been fixed, see PRs 9032 and 9434.
2018-02-11 01:06:03 +09:00
if (HOSTED_VIEWER_ORIGINS.includes(viewerOrigin)) {
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
// Hosted or local viewer, allow for any file locations
return;
}
Revert "Don't block origin-less blob:-URLs in hosted viewer" This reverts commit a6aca3cabe581319d93c862cb0b85f71580cacfd, since no version of Internet Explorer is supported any more.
2022-02-12 19:32:10 +09:00
const fileOrigin = new URL(file, window.location.href).origin;
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
// Removing of the following line will not guarantee that the viewer will
// start accepting URLs from foreign origin -- CORS headers on the remote
// server must be properly configured.
Revert "Don't block origin-less blob:-URLs in hosted viewer" This reverts commit a6aca3cabe581319d93c862cb0b85f71580cacfd, since no version of Internet Explorer is supported any more.
2022-02-12 19:32:10 +09:00
if (fileOrigin !== viewerOrigin) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new Error("file origin does not match viewer's");
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
} catch (ex) {
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-02-22 20:43:16 +09:00
PDFViewerApplication.l10n.get("loading_error").then(msg => {
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-10 23:57:58 +09:00
PDFViewerApplication._documentError(msg, { message: ex?.message });
});
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
throw ex;
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
};
Allow foriegn origin URLs only for hosted viewers.
2016-01-23 02:54:19 +09:00
}
Re-factor the `setupFakeWorkerGlobal` function (in `src/display/api.js`), and the `loadFakeWorker` function (in `web/app.js`) This patch reduces some duplication, by moving *all* fake worker loader code into the `setupFakeWorkerGlobal` function. Furthermore, the functions are simplified further by using `async`/`await` where appropriate.
2019-12-20 02:11:56 +09:00
async function loadFakeWorker() {
Use a bit more optional chaining in the viewer
2022-04-07 23:20:41 +09:00
GlobalWorkerOptions.workerSrc ||= AppOptions.get("workerSrc");
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || !PDFJSDev.test("PRODUCTION")) {
Allow, optionally, using worker-modules during local development Until PR 12563 is deemed safe to land, I'd still like to be able to use worker-modules in the viewer during local development. Hence this patch which *temporarily* adds a new `workerModules` hash-parameter, only available in non-PRODUCTION mode, that allows using worker-modules in the development viewer. To enable this functionality, simply use http://localhost:8888/web/viewer.html#workerModules=true
2023-01-31 20:00:15 +09:00
window.pdfjsWorker = await import("pdfjs/pdf.worker.js");
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-18 22:59:30 +09:00
return;
Move, and modernize, `Util.loadScript` from `src/shared/util.js` to `src/display/dom_utils.js` Not only is the `Util.loadScript` helper function unused on the Worker side, even trying to use it there would throw an Error (since `document` isn't defined/available in Workers). Hence this helper function is moved, and its code modernized slightly by having it return a Promise rather than needing a callback function. Finally, to reduced code duplication, the "new" loadScript function is exported and used in the viewer.
2018-06-07 20:52:40 +09:00
}
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-18 22:59:30 +09:00
await loadScript(PDFWorker.workerSrc);
[api-major] Remove the `PDFJS.disableWorker` option Despite this patch removing the `disableWorker` option itself, please note that we'll still fallback to loading the worker file(s) on the main-thread when running in environments without proper Web Worker support. Furthermore it's still possible, even with this patch, to force the use of fake workers by manually loading the necessary file using a `<script>` tag on the main-thread.[1] That way, the functionality of the now removed `SINGLE_FILE` build target and the resulting `build/pdf.combined.js` file can still be achieved simply by adding e.g. `<script src="build/pdf.worker.js"></script>` to the HTML (obviously with the path adjusted as needed). Finally note that the `disableWorker` option is a performance footgun, and unfortunately many existing third-party examples actually use it without providing any sort of warning/justification. --- [1] This approach is used in the default viewer, since certain kind of debugging may be easier if the code is running directly on the main-thread.
2018-01-20 02:16:17 +09:00
}
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
async function loadPDFBug(self) {
const { debuggerScriptPath } = self.appConfig;
Convert `web/debugger.js` to a *basic* module The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures. Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer. Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally. According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations. --- [1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
const { PDFBug } =
typeof PDFJSDev === "undefined" || !PDFJSDev.test("PRODUCTION")
? await import(debuggerScriptPath) // eslint-disable-line no-unsanitized/method
: await __non_webpack_import__(debuggerScriptPath); // eslint-disable-line no-undef
Move the `PDFBug`-related CSS from `viewer.css` and into its own file Given that none of these CSS rules are used at all, unless debugging is enabled, it seems completely unnecessary to load them *unconditionally* for all users.[1] Note that if *both* the `textLayer` and `pdfBug` debugging hash-parameters are specified simultaneously, we'll now load the `PDFBug`-file *twice* (since the code is simpler that way). However, given first of all that none of this is enabled by default and secondly that using those parameters together isn't helpful[2], potentially loading that file twice is hopefully not an issue. For the `gulp mozcentral` target, the size of the *built* `viewer.css` file is reduced `> 3%` with this patch. --- [1] For the Firefox built-in PDF Viewer, in order to even be able to access the `PDFBug` functionality, you need to first of all set `pdfjs.pdfBugEnabled = true` manually in `about:config`. Secondly, you then also need to append the `pdfBug=...` hash-parameter to the URL when *initially* loading the document. [2] Note how the `textLayer`-settings are already, since essentially forever, overriding the highlighting-features of the "FontInspector"-tab.
2022-04-06 01:14:17 +09:00
self._PDFBug = PDFBug;
Enables debugger only when needed.
2016-05-10 08:18:43 +09:00
}
Remove the `PDFPageView.stats` property, and fetch it manually only when debugging is enabled Given that the default viewer only uses the "page stats" when debugging is enabled, it seems much simpler and more straightforward to simply query the API *directly* when this information is actually required. That way, there's a bit less information that needs to be stored/updated on each `PDFPageView`-instance. Finally, since the `EventBus` now exists, we no longer need to handle the "page stats"-case in the regular listeners in `web/app.js`, but can instead add special "page stats"-listeners only when debugging is enabled.
2020-09-23 21:39:14 +09:00
function reportPageStatsPDFBug({ pageNumber }) {
Convert `web/debugger.js` to a *basic* module The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures. Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer. Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally. According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations. --- [1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
if (!globalThis.Stats?.enabled) {
Remove the `PDFPageView.stats` property, and fetch it manually only when debugging is enabled Given that the default viewer only uses the "page stats" when debugging is enabled, it seems much simpler and more straightforward to simply query the API *directly* when this information is actually required. That way, there's a bit less information that needs to be stored/updated on each `PDFPageView`-instance. Finally, since the `EventBus` now exists, we no longer need to handle the "page stats"-case in the regular listeners in `web/app.js`, but can instead add special "page stats"-listeners only when debugging is enabled.
2020-09-23 21:39:14 +09:00
return;
}
const pageView = PDFViewerApplication.pdfViewer.getPageView(
/* index = */ pageNumber - 1
);
Convert `web/debugger.js` to a *basic* module The various functionality in `web/debugger.js` is currently *indirectly* added to the global scope, since that's how `var` works when it's used outside of any functions/closures. Given how this functionality is being accessed/used, not just in the viewer but also in the API and textLayer, simply converting the entire file to a module isn't trivial[1]. However, we can at least export the `PDFBug`-part properly and then `import` that dynamically in the viewer. Also, to improve the code a little bit, we're now *explicitly* exporting the necessary functionality globally. According to MDN, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility, all the browsers that we now support have dynamic `imports` implementations. --- [1] We could probably pass around references to the necessary functionality, but given how this is being used I'm just not sure it's worth the effort. Also, adding *official* support for these viewer-specific debugging tools in the API feels both unnecessary and unfortunate.
2022-04-03 18:51:49 +09:00
globalThis.Stats.add(pageNumber, pageView?.pdfPage?.stats);
Remove the `PDFPageView.stats` property, and fetch it manually only when debugging is enabled Given that the default viewer only uses the "page stats" when debugging is enabled, it seems much simpler and more straightforward to simply query the API *directly* when this information is actually required. That way, there's a bit less information that needs to be stored/updated on each `PDFPageView`-instance. Finally, since the `EventBus` now exists, we no longer need to handle the "page stats"-case in the regular listeners in `web/app.js`, but can instead add special "page stats"-listeners only when debugging is enabled.
2020-09-23 21:39:14 +09:00
}
Add enableWebGL to the preferences
2014-04-04 02:20:53 +09:00
function webViewerInitialized() {
Reduce a tiny bit of duplication in the `webViewerInitialized` function
2023-02-05 06:56:20 +09:00
const { appConfig, eventBus, l10n } = PDFViewerApplication;
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
let file;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const queryString = document.location.search.substring(1);
const params = parseQueryString(queryString);
Change the `parseQueryString` function to return a `Map` rather than an Object (issue 13829) Even though the code as-is *should* be safe, given that we're using an Object with a `null` prototype, it cannot hurt to change this to a Map to prevent any issues (since we're parsing unknown and potentially unsafe data). Overall I also think that these changes improve the `parseQueryString` call-sites, since we now have a proper way of checking for the existence of a particular key (and don't have to use `in` which stringifies the keys in the Object). This patch also changes the default, when no `value` exists, from `null` to an empty string since the use of `decodeURIComponent` currently can modify the value in a somewhat surprising way (at least to me). Note how `decodeURIComponent(null) === "null"` which is unlikely to be what you actually want, whereas `decodeURIComponent("") === ""` which seems much more helpful.
2021-08-01 05:15:30 +09:00
file = params.get("file") ?? AppOptions.get("defaultUrl");
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
validateFileURL(file);
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
} else if (PDFJSDev.test("MOZCENTRAL")) {
[Firefox] Allow PDF attachments to, once again, be opened directly in the browser (bug 1632644) Apparently the old link format used in MOZCENTRAL-builds, with the blob URL separated from the filename with a `?` character violates the specification; see https://bugzilla.mozilla.org/show_bug.cgi?id=1632644#c5 Obviously just removing the `?`-part of the URL would have worked, but that would also have meant that we'd no longer be able to provide the correct filename when the user attempts to download the opened PDF attachment. To fix this we'll instead append the filename in the hash-part of the URL, which however required using a *custom* hash-parameter to avoid triggering the fallback "named destination" code-paths in the viewer. Note that only changing the `web/pdf_attachment_viewer.js` file wasn't sufficient to fix the bug, and we also need to tweak the `webViewerInitialized` function in `web/app.js` since MOZCENTRAL-builds used to ignore *everything* in the URL hash. This particular code is very old, but changing it *should* be completely safe given that the `PDFViewerApplication.setTitleUsingUrl` method since some time now stores both the original URL (in `this.url`) as well as one without the hash (in `this.baseUrl`). The latter one is already used everywhere where it matters, so this change seem fine to me. This patch thus restores the original behaviour for PDF attachments in the MOZCENTRAL-build, by once again allowing them to be opened *directly* in the browser without downloading. (The fallback added in PR 11845 is obviously kept, since it seems generally useful to have.)
2020-05-20 18:27:29 +09:00
file = window.location.href;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
} else if (PDFJSDev.test("CHROME")) {
file = AppOptions.get("defaultUrl");
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
[CRX] Fixes to view local files again pdfHandler-local.js references the isPdfDownloadable function from pdfHandler.js, but the function didn't expect that the responseHeaders property was absent. Added a check to prevent a runtime error when a local file is displayed in a frame, and show local PDF files again. Local files are rendered on the chrome-extension:-protocol. The previous method of getting the PDF URL was incorrect, this has been fixed as well.
2013-08-15 06:36:40 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
const fileInput = appConfig.openFileInput;
[GENERIC viewer] Remove some, now unnecessary, checks used with `fileInput` According to the MDN compatibility data, see below, all of these features have been supported for years and years in all browsers. Looking closely at the data, the most likely reason for adding these checks in the first place was for IE 9 compatibility (since we originally "supported" that browser). - https://developer.mozilla.org/en-US/docs/Web/API/File#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/FileReader#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/FileList#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/API/Blob#browser_compatibility
2022-04-10 19:50:35 +09:00
fileInput.value = null;
Ignore 'change' events that didn't originate in the viewer (issue 8915) Rather that registering a 'change' event listener on the `window`, which will thus (unnecessarily) fire in *a number* of other situations such as e.g. when the user changes the pageNumber or the current search term, we could/should just register it directly on the dynamically created `fileInput` DOM element instead. I can see no really compelling reason why we actually need to listen for `file` changes on the `window` itself, and this way we're also able to keep the `fileInput` related code confined to one part of the code which should aid readability. Furthermore, in custom deployments, there's less risk that we're going to interfere with "outside" code this way. Finally, preprocessor guards were added to the `webViewerOpenFile` function, since that code doesn't make sense in e.g. the extension builds.
2017-09-16 20:05:01 +09:00
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
fileInput.addEventListener("change", function (evt) {
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
const { files } = evt.target;
Ignore 'change' events that didn't originate in the viewer (issue 8915) Rather that registering a 'change' event listener on the `window`, which will thus (unnecessarily) fire in *a number* of other situations such as e.g. when the user changes the pageNumber or the current search term, we could/should just register it directly on the dynamically created `fileInput` DOM element instead. I can see no really compelling reason why we actually need to listen for `file` changes on the `window` itself, and this way we're also able to keep the `fileInput` related code confined to one part of the code which should aid readability. Furthermore, in custom deployments, there's less risk that we're going to interfere with "outside" code this way. Finally, preprocessor guards were added to the `webViewerOpenFile` function, since that code doesn't make sense in e.g. the extension builds.
2017-09-16 20:05:01 +09:00
if (!files || files.length === 0) {
return;
}
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
eventBus.dispatch("fileinputchange", {
Add `source` parameters to all remaining `EventBus.dispatch` calls that are currently missing those This is necessary for subsequent patches, and will help avoid unnecessary event re-dispatching in cases where the event source is `window`.
2018-08-28 16:56:26 +09:00
source: this,
Ignore 'change' events that didn't originate in the viewer (issue 8915) Rather that registering a 'change' event listener on the `window`, which will thus (unnecessarily) fire in *a number* of other situations such as e.g. when the user changes the pageNumber or the current search term, we could/should just register it directly on the dynamically created `fileInput` DOM element instead. I can see no really compelling reason why we actually need to listen for `file` changes on the `window` itself, and this way we're also able to keep the `fileInput` related code confined to one part of the code which should aid readability. Furthermore, in custom deployments, there's less risk that we're going to interfere with "outside" code this way. Finally, preprocessor guards were added to the `webViewerOpenFile` function, since that code doesn't make sense in e.g. the extension builds.
2017-09-16 20:05:01 +09:00
fileInput: evt.target,
});
});
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
Fix typo
2020-03-07 12:37:22 +09:00
// Enable dragging-and-dropping a new PDF file onto the viewerContainer.
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
appConfig.mainContainer.addEventListener("dragover", function (evt) {
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
evt.preventDefault();
Set 'dropEffect' based on 'effectAllowed' for drag-and-drop in the viewer (issue 14942). See https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer/effectAllowed
2022-05-21 14:48:44 +09:00
evt.dataTransfer.dropEffect =
evt.dataTransfer.effectAllowed === "copy" ? "copy" : "move";
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
});
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
appConfig.mainContainer.addEventListener("drop", function (evt) {
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
evt.preventDefault();
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
const { files } = evt.dataTransfer;
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
if (!files || files.length === 0) {
return;
}
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
eventBus.dispatch("fileinputchange", {
Add `source` parameters to all remaining `EventBus.dispatch` calls that are currently missing those This is necessary for subsequent patches, and will help avoid unnecessary event re-dispatching in cases where the event source is `window`.
2018-08-28 16:56:26 +09:00
source: this,
Implement drag-and-drop support in the viewer for local files
2018-06-10 22:39:06 +09:00
fileInput: evt.dataTransfer,
});
});
Hide the browse bar for the ff extension.
2012-01-25 08:13:50 +09:00
}
Moves all document.getElementById lookups into viewer.js
2016-04-22 01:39:11 +09:00
Remove a couple of unnecessary `PDFJSDev` checks from the viewer - Given the `DefaultExternalServices` implementation, the `PDFViewerApplication.supportsDocumentFonts` getter is guaranteed to be defined and we can thus remove some (now) unnecessary `PDFJSDev` checks from the `webViewerInitialized` function. - By slightly tweaking the "pdfBugEnabled" definition in `web/app_options`, similar to the existing ones for "workerSrc" and "cMapUrl", we can remove some `PDFJSDev` checks from the `PDFViewerApplication._parseHashParameters` method.
2020-07-24 01:06:02 +09:00
if (!PDFViewerApplication.supportsDocumentFonts) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
AppOptions.set("disableFontFace", true);
Reduce a tiny bit of duplication in the `webViewerInitialized` function
2023-02-05 06:56:20 +09:00
l10n.get("web_fonts_disabled").then(msg => {
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-10 23:57:58 +09:00
console.warn(msg);
});
Enable linting of Firefox specific code in viewer.js - This patch uncomments a large portion of the Firefox specific code in viewer.js, by using a preprocessor "trick", to enable linting. Doing this actually uncovered some issues, e.g. variables defined multiple times. - This patch also fixes a spelling error, `adobe pdfwritter` -> `abobe pdfwriter`, in the `KNOWN_GENERATORS` list used when reporting telemetry data in Firefox. *Please note:* there's still some Firefox specific code that is commented out, but it's usually just one (or two) lines of code. Hence the risk that errors creep in should be much lower, compared to entire code-blocks.
2015-04-26 08:49:37 +09:00
}
Initial localization
2012-05-01 05:29:05 +09:00
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
if (!PDFViewerApplication.supportsPrinting) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
appConfig.toolbar?.print.classList.add("hidden");
appConfig.secondaryToolbar?.printButton.classList.add("hidden");
Localize print message. Show/hide print button.
2012-07-10 08:04:55 +09:00
}
Protect a few additional DOM element accesses in the viewer (PR 15831 follow-up) A couple of cases that I missed during review, for code-paths that don't run by default in the viewer.
2022-12-16 02:48:10 +09:00
if (!PDFViewerApplication.supportsFullscreen) {
appConfig.secondaryToolbar?.presentationModeButton.classList.add("hidden");
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
}
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
if (PDFViewerApplication.supportsIntegratedFind) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
appConfig.toolbar?.viewFind.classList.add("hidden");
Add support for firefox integrated find.
2012-10-06 05:59:13 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
appConfig.mainContainer.addEventListener(
"transitionend",
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
function (evt) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (evt.target === /* mainContainer */ this) {
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
eventBus.dispatch("resize", { source: this });
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
},
true
);
Changes to allowed versioned building of Chrome extension that meets new Chrome extension security requirements
2012-09-07 00:33:07 +09:00
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
try {
Inline the `webViewerOpenFileViaURL` function in `webViewerInitialized` Given that `webViewerOpenFileViaURL` only has a single call-site, and also isn't a particularly large/complex function, it doesn't seem necessary for this to be a separate function and hence it's simply inlined instead. Also, changes the "no valid build-target was set"-case to throw unconditionally since the only way that it could ever be hit is if there are bugs in the `gulpfile`-code.
2022-04-30 00:04:56 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
if (file) {
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
PDFViewerApplication.open({ url: file });
Inline the `webViewerOpenFileViaURL` function in `webViewerInitialized` Given that `webViewerOpenFileViaURL` only has a single call-site, and also isn't a particularly large/complex function, it doesn't seem necessary for this to be a separate function and hence it's simply inlined instead. Also, changes the "no valid build-target was set"-case to throw unconditionally since the only way that it could ever be hit is if there are bugs in the `gulpfile`-code.
2022-04-30 00:04:56 +09:00
} else {
PDFViewerApplication._hideViewBookmark();
}
} else if (PDFJSDev.test("MOZCENTRAL || CHROME")) {
PDFViewerApplication.setTitleUsingUrl(file, /* downloadUrl = */ file);
PDFViewerApplication.initPassiveLoading();
} else {
throw new Error("Not implemented: webViewerInitialized");
}
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
} catch (reason) {
Reduce a tiny bit of duplication in the `webViewerInitialized` function
2023-02-05 06:56:20 +09:00
l10n.get("loading_error").then(msg => {
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-10 23:57:58 +09:00
PDFViewerApplication._documentError(msg, reason);
});
Refactor a number of methods in `PDFViewerApplication` to be `async` rather than manually returning `Promise`s *Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
2018-07-31 00:41:39 +09:00
}
Enables debugger only when needed.
2016-05-10 08:18:43 +09:00
}
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into loadingbychrome Conflicts: web/viewer.js
2012-08-16 00:17:30 +09:00
Only display the pageNumber-loadingIcon when rendering is currently running *This makes the same kind of changes as in the previous patch, but for the pageNumber-loadingIcon in the main toolbar.* To display the pageNumber-loadingIcon when rendering starts, if the page is the most visible one, we'll utilize the existing "pagerender" event. To toggle the pageNumber-loadingIcon as the user moves through the document we'll now instead utilize the "pagechanging" event, which should actually be slightly more efficient overall[1]. Note how we'd, in the old code, only consider the most visible page anyway when toggling the pageNumber-loadingIcon. --- [1] Even in a PDF document as relatively short/simple as `tracemonkey.pdf`, scrolling through the entire document can easily trigger the "updateviewarea" event more than a thousand times.
2022-12-26 23:00:30 +09:00
function webViewerPageRender({ pageNumber }) {
// If the page is (the most) visible when it starts rendering,
// ensure that the page number input loading indicator is displayed.
if (pageNumber === PDFViewerApplication.page) {
PDFViewerApplication.toolbar?.updateLoadingIndicatorState(true);
}
}
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 20:36:06 +09:00
function webViewerPageRendered({ pageNumber, error }) {
Ensure that any pending rendering operations in `PDFViewer`/`PDFThumbnailViewer` are cancelled when the viewer is closed
2016-07-30 03:39:22 +09:00
// If the page is still visible when it has finished rendering,
// ensure that the page number input loading indicator is hidden.
if (pageNumber === PDFViewerApplication.page) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.toolbar?.updateLoadingIndicatorState(false);
Ensure that any pending rendering operations in `PDFViewer`/`PDFThumbnailViewer` are cancelled when the viewer is closed
2016-07-30 03:39:22 +09:00
}
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
// Use the rendered page to set the corresponding thumbnail image.
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.pdfSidebar?.visibleView === SidebarView.THUMBS) {
Update all `BaseViewer.getPageView`/`PDFThumbnailViewer.getThumbnail` call-sites, in `web/app.js`, to check the returned value properly Given how those are used, there *should* not be any situation in which e.g. `undefined` is ever returned. However, actually checking that the pageView/thumbnail is defined cannot hurt. Also, re-factor `webViewerPageRendered` slightly since the `pageView` is no longer unconditionally necessary after the previous patches; note in particular that the thumbnails will only be updated when the sidebar *and* the thumbnailView is visible. Finally, fixes a bug in `webViewerPageChanging` whereby an empty string would not be treated as a valid pageLabel and instead be replaced by `null`.
2020-09-23 22:38:54 +09:00
const pageView = PDFViewerApplication.pdfViewer.getPageView(
/* index = */ pageNumber - 1
);
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
const thumbnailView = PDFViewerApplication.pdfThumbnailViewer?.getThumbnail(
Update all `BaseViewer.getPageView`/`PDFThumbnailViewer.getThumbnail` call-sites, in `web/app.js`, to check the returned value properly Given how those are used, there *should* not be any situation in which e.g. `undefined` is ever returned. However, actually checking that the pageView/thumbnail is defined cannot hurt. Also, re-factor `webViewerPageRendered` slightly since the `pageView` is no longer unconditionally necessary after the previous patches; note in particular that the thumbnails will only be updated when the sidebar *and* the thumbnailView is visible. Finally, fixes a bug in `webViewerPageChanging` whereby an empty string would not be treated as a valid pageLabel and instead be replaced by `null`.
2020-09-23 22:38:54 +09:00
/* index = */ pageNumber - 1
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
Update all `BaseViewer.getPageView`/`PDFThumbnailViewer.getThumbnail` call-sites, in `web/app.js`, to check the returned value properly Given how those are used, there *should* not be any situation in which e.g. `undefined` is ever returned. However, actually checking that the pageView/thumbnail is defined cannot hurt. Also, re-factor `webViewerPageRendered` slightly since the `pageView` is no longer unconditionally necessary after the previous patches; note in particular that the thumbnails will only be updated when the sidebar *and* the thumbnailView is visible. Finally, fixes a bug in `webViewerPageChanging` whereby an empty string would not be treated as a valid pageLabel and instead be replaced by `null`.
2020-09-23 22:38:54 +09:00
if (pageView && thumbnailView) {
thumbnailView.setImage(pageView);
}
Update thumbnail images only when sidebar is visible
2015-01-28 05:13:34 +09:00
}
Improved page tracking on scrolling [squashed]
2012-08-08 08:52:22 +09:00
Remove the `PDFPageView.error` property, and simply include Errors in the "pagerendered" event instead The way that rendering errors are handled in `PDFPageView` is *very* old, and predates e.g. the introduction of the `EventBus` by several years. Hence we should be able to simplify things a bit here, by including the Error (when it exists) in the "pagerendered" event and thus avoid having to reach into `PDFPageView` for it.
2020-09-23 21:29:21 +09:00
if (error) {
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-02-22 20:43:16 +09:00
PDFViewerApplication.l10n.get("rendering_error").then(msg => {
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-10 23:57:58 +09:00
PDFViewerApplication._otherError(msg, error);
});
Removes any usage of PDFView in the PageView
2014-09-16 04:57:12 +09:00
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Improved page tracking on scrolling [squashed]
2012-08-08 08:52:22 +09:00
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule in the `web/` directory This covers the handful of cases that the `--fix` command couldn't deal with, and the changes aren't just fixing the linting errors but attempt to slightly improve the relevant code.
2019-12-27 08:32:40 +09:00
function webViewerPageMode({ mode }) {
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
// Handle the 'pagemode' hash parameter, see also `PDFLinkService_setHash`.
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule in the `web/` directory This covers the handful of cases that the `--fix` command couldn't deal with, and the changes aren't just fixing the linting errors but attempt to slightly improve the relevant code.
2019-12-27 08:32:40 +09:00
let view;
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
switch (mode) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "thumbs":
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
view = SidebarView.THUMBS;
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "bookmarks":
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
case "outline": // non-standard
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
view = SidebarView.OUTLINE;
break;
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
case "attachments": // non-standard
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
view = SidebarView.ATTACHMENTS;
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
break;
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
case "layers": // non-standard
view = SidebarView.LAYERS;
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "none":
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
view = SidebarView.NONE;
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
break;
Move the sidebar related code from viewer.js into `PDFSidebar` The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years. To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years. Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed). This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
2016-02-22 01:54:23 +09:00
default:
console.error('Invalid "pagemode" hash parameter: ' + mode);
return;
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
}
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.pdfSidebar?.switchView(view, /* forceOpen = */ true);
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Move handling of the 'pagemode' hash parameter into `viewer.js` to restore the functionality This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012. Since the 'pagemode' hash parameter requires certain viewer functionality (e.g. thumbnails and an outline) in order to work, it seemed reasonable to move the functionality from `pdf_link_service.js` into `viewer.js`. Similar to `namedaction`, this patch makes use of an event to forward the 'pagemode' parameter.
2015-08-05 05:57:51 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerNamedAction(evt) {
Add support for /Print and /SaveAs named actions in the viewer (issue 12308) All of the core/display functionality needed to support this already exists, we simply need to handle these named actions in the viewer and the buttons will "just" work. Unfortunately there's not really any good way of testing this, but given the size and scope of the patch that's hopefully OK.
2020-09-01 15:54:07 +09:00
// Processing a couple of named actions that might be useful, see also
// `PDFLinkService.executeNamedAction`.
switch (evt.action) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "GoToPage":
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.appConfig.toolbar?.pageNumber.select();
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "Find":
Fix 'namedaction' regression that breaks the 'Find' action This regressed in https://github.com/mozilla/pdf.js/commit/0ef6212b646427604b6968b8bc3cf2d6c048f012.
2015-08-05 06:07:44 +09:00
if (!PDFViewerApplication.supportsIntegratedFind) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication?.findBar.toggle();
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
}
break;
Add support for /Print and /SaveAs named actions in the viewer (issue 12308) All of the core/display functionality needed to support this already exists, we simply need to handle these named actions in the viewer and the buttons will "just" work. Unfortunately there's not really any good way of testing this, but given the size and scope of the patch that's hopefully OK.
2020-09-01 15:54:07 +09:00
case "Print":
Re-factor how printing is triggered in the default viewer This adds a new `PDFViewerApplication.triggerPrinting` method, which takes care of checking that printing is actually supported before calling `window.print`, to remove the need to duplicate that code in multiple places. Also, removes the `PDFViewerApplication.printing` getter since it's not really necessary any more.
2020-09-30 22:02:11 +09:00
PDFViewerApplication.triggerPrinting();
Add support for /Print and /SaveAs named actions in the viewer (issue 12308) All of the core/display functionality needed to support this already exists, we simply need to handle these named actions in the viewer and the buttons will "just" work. Unfortunately there's not really any good way of testing this, but given the size and scope of the patch that's hopefully OK.
2020-09-01 15:54:07 +09:00
break;
case "SaveAs":
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
PDFViewerApplication.downloadOrSave();
Add support for /Print and /SaveAs named actions in the viewer (issue 12308) All of the core/display functionality needed to support this already exists, we simply need to handle these named actions in the viewer and the buttons will "just" work. Unfortunately there's not really any good way of testing this, but given the size and scope of the patch that's hopefully OK.
2020-09-01 15:54:07 +09:00
break;
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Refactors PDFLinkService. # Conflicts: # web/viewer.js
2015-04-28 00:25:32 +09:00
Include the `state` in the "presentationmodechanged" event, and remove the separate `active`/`switchInProgress` properties Given that we already have a `PresentationModeState`-enumeration, we should use that with the "presentationmodechanged" event rather than including separate properties. Note that this new behaviour, of including an enumeration-value in the event, is consistent with lots of other existing viewer-events. To hopefully avoid issues in custom implementations of the default viewer, any attempt to access the removed properties will now throw.
2020-12-29 01:03:27 +09:00
function webViewerPresentationModeChanged(evt) {
PDFViewerApplication.pdfViewer.presentationModeState = evt.state;
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Improved page tracking on scrolling [squashed]
2012-08-08 08:52:22 +09:00
Remove the `view`-specific getters in the `PDFSidebar` class With the exception of `isThumbnailViewVisible`, these getters are completely unused. Generally speaking, using the `visibleView`-getter directly works just as well and seems (at least to me) to be overall preferable considering how our classes are usually implemented.
2022-05-26 18:58:36 +09:00
function webViewerSidebarViewChanged({ view }) {
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
PDFViewerApplication.pdfRenderingQueue.isThumbnailViewEnabled =
Remove the `view`-specific getters in the `PDFSidebar` class With the exception of `isThumbnailViewVisible`, these getters are completely unused. Generally speaking, using the `visibleView`-getter directly works just as well and seems (at least to me) to be overall preferable considering how our classes are usually implemented.
2022-05-26 18:58:36 +09:00
view === SidebarView.THUMBS;
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
if (PDFViewerApplication.isInitialViewSet) {
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
// Only update the storage when the document has been loaded *and* rendered.
Remove the `view`-specific getters in the `PDFSidebar` class With the exception of `isThumbnailViewVisible`, these getters are completely unused. Generally speaking, using the `visibleView`-getter directly works just as well and seems (at least to me) to be overall preferable considering how our classes are usually implemented.
2022-05-26 18:58:36 +09:00
PDFViewerApplication.store?.set("sidebarView", view).catch(() => {
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
// Unable to write to storage.
});
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
Remove the `view`-specific getters in the `PDFSidebar` class With the exception of `isThumbnailViewVisible`, these getters are completely unused. Generally speaking, using the `visibleView`-getter directly works just as well and seems (at least to me) to be overall preferable considering how our classes are usually implemented.
2022-05-26 18:58:36 +09:00
function webViewerUpdateViewarea({ location }) {
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
if (PDFViewerApplication.isInitialViewSet) {
// Only update the storage when the document has been loaded *and* rendered.
PDFViewerApplication.store
?.setMultiple({
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
page: location.pageNumber,
zoom: location.scale,
scrollLeft: location.left,
scrollTop: location.top,
rotation: location.rotation,
})
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
.catch(() => {
// Unable to write to storage.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Dispatch a `sidebarviewchanged` event in `PDFSidebar` when the view changes We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event. Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing. This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
2016-03-12 21:07:43 +09:00
}
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.appConfig.secondaryToolbar) {
Only display the pageNumber-loadingIcon when rendering is currently running *This makes the same kind of changes as in the previous patch, but for the pageNumber-loadingIcon in the main toolbar.* To display the pageNumber-loadingIcon when rendering starts, if the page is the most visible one, we'll utilize the existing "pagerender" event. To toggle the pageNumber-loadingIcon as the user moves through the document we'll now instead utilize the "pagechanging" event, which should actually be slightly more efficient overall[1]. Note how we'd, in the old code, only consider the most visible page anyway when toggling the pageNumber-loadingIcon. --- [1] Even in a PDF document as relatively short/simple as `tracemonkey.pdf`, scrolling through the entire document can easily trigger the "updateviewarea" event more than a thousand times.
2022-12-26 23:00:30 +09:00
const href = PDFViewerApplication.pdfLinkService.getAnchorUrl(
location.pdfOpenParams
);
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.appConfig.secondaryToolbar.viewBookmarkButton.href =
href;
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Zooming control
2011-09-03 10:16:52 +09:00
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
function webViewerScrollModeChanged(evt) {
Don't update the Scroll/Spread-mode in the ViewHistory while PresentationMode is active (issue 15453) By force-quitting the browser while the FullScreen API is active, we don't get a chance to exit PresentationMode *cleanly* and some of its state thus remains (via the `ViewHistory`). To try and improve things here we can skip updating the Scroll/Spread-mode while PresentationMode is active, since they will be changed when entering PresentationMode, which seems to help and is really the best that we can do here (and what the issue describes is very much an edge-case anyway).
2022-09-18 18:34:03 +09:00
if (
PDFViewerApplication.isInitialViewSet &&
!PDFViewerApplication.pdfViewer.isInPresentationMode
) {
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
// Only update the storage when the document has been loaded *and* rendered.
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
PDFViewerApplication.store?.set("scrollMode", evt.mode).catch(() => {
// Unable to write to storage.
});
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
}
}
function webViewerSpreadModeChanged(evt) {
Don't update the Scroll/Spread-mode in the ViewHistory while PresentationMode is active (issue 15453) By force-quitting the browser while the FullScreen API is active, we don't get a chance to exit PresentationMode *cleanly* and some of its state thus remains (via the `ViewHistory`). To try and improve things here we can skip updating the Scroll/Spread-mode while PresentationMode is active, since they will be changed when entering PresentationMode, which seems to help and is really the best that we can do here (and what the issue describes is very much an edge-case anyway).
2022-09-18 18:34:03 +09:00
if (
PDFViewerApplication.isInitialViewSet &&
!PDFViewerApplication.pdfViewer.isInPresentationMode
) {
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
// Only update the storage when the document has been loaded *and* rendered.
Use optional chaining to simplify `PDFViewerApplication.store` accesses in various event handlers This way we no longer need the intermediate variables.
2021-11-02 20:00:57 +09:00
PDFViewerApplication.store?.set("spreadMode", evt.mode).catch(() => {
// Unable to write to storage.
});
Remember last used scroll and spread modes
2018-05-15 12:10:33 +09:00
}
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
function webViewerResize() {
Ignoring "resize" events during printing (issue 15324) This is a quick work-around, to prevent the viewer from breaking as a result of https://bugzilla.mozilla.org/show_bug.cgi?id=774398
2022-08-16 20:02:46 +09:00
const { pdfDocument, pdfViewer, pdfRenderingQueue } = PDFViewerApplication;
if (pdfRenderingQueue.printing && window.matchMedia("print").matches) {
// Work-around issue 15324 by ignoring "resize" events during printing.
return;
}
Introduce a `--viewer-container-height` CSS variable to simplify the code This new CSS variable will allow us to simplify a couple of different viewer components, since we no longer need to use JavaScript-based hacks and can directly set the CSS rules instead. In particular: - The `BaseViewer`-handling, used as part of the code that will center pages *vertically* in PresentationMode, can be simplified. By using CSS to control the height of the "dummy"-page we avoid unnecessarily invalidating the scale-value, which can reduce *some* unneeded re-rendering while PresentationMode is active. - The `SecondaryToolbar.#setMaxHeight`-method, and its associated parameters, are no longer necessary and can be completely removed. Note that in order for things to work correctly in general, the new `--viewer-container-height` CSS variable must potentially be updated on any window-based "resize"-event (even when there's no zooming). While this is currently only done in the default viewer, that shouldn't be an issue since neither PresentationMode nor Toolbar-functionality is included in the "viewer components".
2022-05-06 00:37:33 +09:00
Remove the scale-not-initialized hack from `webViewerResize` (in app.js) Since we no longer, after PR 8555, allow changing the scale until the document is loaded, that hack is no longer necessary. Furthermore, no part of that event handling function needs to run unless a document is loaded. The reason that this hack was initially added, is that previously the `ViewHistory` might be updated *before* `PDFViewerApplication.setInitialView` had run (in some cases leading to incorrect inital document scale). Since that is no longer possible, this is now dead code.
2017-07-06 20:13:22 +09:00
if (!pdfDocument) {
return;
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const currentScaleValue = pdfViewer.currentScaleValue;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
currentScaleValue === "auto" ||
currentScaleValue === "page-fit" ||
currentScaleValue === "page-width"
) {
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
// Note: the scale is constant for 'page-actual'.
Remove the scale-not-initialized hack from `webViewerResize` (in app.js) Since we no longer, after PR 8555, allow changing the scale until the document is loaded, that hack is no longer necessary. Furthermore, no part of that event handling function needs to run unless a document is loaded. The reason that this hack was initially added, is that previously the `ViewHistory` might be updated *before* `PDFViewerApplication.setInitialView` had run (in some cases leading to incorrect inital document scale). Since that is no longer possible, this is now dead code.
2017-07-06 20:13:22 +09:00
pdfViewer.currentScaleValue = currentScaleValue;
Keep current scroll position when zooming the document
2013-08-01 02:43:03 +09:00
}
Remove the scale-not-initialized hack from `webViewerResize` (in app.js) Since we no longer, after PR 8555, allow changing the scale until the document is loaded, that hack is no longer necessary. Furthermore, no part of that event handling function needs to run unless a document is loaded. The reason that this hack was initially added, is that previously the `ViewHistory` might be updated *before* `PDFViewerApplication.setInitialView` had run (in some cases leading to incorrect inital document scale). Since that is no longer possible, this is now dead code.
2017-07-06 20:13:22 +09:00
pdfViewer.update();
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Zooming control
2011-09-03 10:16:52 +09:00
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerHashchange(evt) {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const hash = evt.hash;
Rip out the current implementation of `PDFHistory` The current implementation of `PDFHistory` contains a number of smaller bugs, which are *very* difficult to address without breaking other parts of its code. Possibly the main issue with the current implementation, is that I wrote it quite some time ago, and at the time my understanding of the various edge-cases the code has to deal with was quite limited. Currently `PDFHistory` may, despite most of those cases being fixed, in certain edge-cases lock-up the browser history, essentially preventing the user from navigating back/forward. Hence rather than trying to iterate on `PDFHistory` to make it better, the only viable approach is unfortunately rip it out in its entirety and re-write it from scratch.
2017-07-14 21:24:32 +09:00
if (!hash) {
return;
}
if (!PDFViewerApplication.isInitialViewSet) {
PDFViewerApplication.initialBookmark = hash;
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 21:21:15 +09:00
} else if (!PDFViewerApplication.pdfHistory?.popStateInProgress) {
Rip out the current implementation of `PDFHistory` The current implementation of `PDFHistory` contains a number of smaller bugs, which are *very* difficult to address without breaking other parts of its code. Possibly the main issue with the current implementation, is that I wrote it quite some time ago, and at the time my understanding of the various edge-cases the code has to deal with was quite limited. Currently `PDFHistory` may, despite most of those cases being fixed, in certain edge-cases lock-up the browser history, essentially preventing the user from navigating back/forward. Hence rather than trying to iterate on `PDFHistory` to make it better, the only viable approach is unfortunately rip it out in its entirety and re-write it from scratch.
2017-07-14 21:24:32 +09:00
PDFViewerApplication.pdfLinkService.setHash(hash);
PDF browsing history - v6.50
2013-05-16 07:31:17 +09:00
}
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
Only define the `webViewerFileInputChange`/`webViewerOpenFile` variables in GENERIC builds There's no point in having these variables defined (implicitly) as `undefined` in e.g. the Firefox PDF Viewer. By defining them with `var` and using ESList ignores, rather than `let`, we can move them into the relevant pre-processor block instead. Note that since the entire viewer-code is placed, by Webpack, in a top-level closure these variables will thus *not* become globally accessible.
2022-04-30 00:36:52 +09:00
// eslint-disable-next-line no-var
var webViewerFileInputChange = function (evt) {
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-06 01:36:28 +09:00
if (PDFViewerApplication.pdfViewer?.isInPresentationMode) {
Disable (drag-and-drop) file opening if Presentation Mode is active (PR 9794 follow-up)
2018-06-11 17:48:36 +09:00
return; // Opening a new PDF file isn't supported in Presentation Mode.
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const file = evt.fileInput.files[0];
Using blob URL for open file
2014-01-28 04:11:02 +09:00
Change the `PDFViewerApplication.open` method to only accept objects If this method was added today, I really can't imagine that we'd support anything *except* objects. Unfortunately we cannot just remove this now, since the code has existed since "forever", however we can deprecate this and limit it to only the GENERIC build. Furthermore, we can avoid a redundant `PDFViewerApplication.setTitleUsingUrl` call in the Firefox PDF Viewer since the title has already been set previously in that case.
2023-01-28 21:03:03 +09:00
PDFViewerApplication.open({
url: URL.createObjectURL(file),
originalUrl: file.name,
});
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
};
Move the `webViewerOpenFile` function, and the "openfile" eventBus listener, since they only matter in GENERIC builds of the default viewer This is similar to the existing implementation of the `webViewerFileInputChange` function and its associated "fileinputchange" event.
2020-03-17 21:26:35 +09:00
Only define the `webViewerFileInputChange`/`webViewerOpenFile` variables in GENERIC builds There's no point in having these variables defined (implicitly) as `undefined` in e.g. the Firefox PDF Viewer. By defining them with `var` and using ESList ignores, rather than `let`, we can move them into the relevant pre-processor block instead. Note that since the entire viewer-code is placed, by Webpack, in a top-level closure these variables will thus *not* become globally accessible.
2022-04-30 00:36:52 +09:00
// eslint-disable-next-line no-var
var webViewerOpenFile = function (evt) {
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
const fileInput = PDFViewerApplication.appConfig.openFileInput;
fileInput.click();
Move the `webViewerOpenFile` function, and the "openfile" eventBus listener, since they only matter in GENERIC builds of the default viewer This is similar to the existing implementation of the `webViewerFileInputChange` function and its associated "fileinputchange" event.
2020-03-17 21:26:35 +09:00
};
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
function webViewerPresentationMode() {
PDFViewerApplication.requestPresentationMode();
}
[edition] Add a FreeText editor (#14970) - add a basic UI to edit some text in a pdf; - an editor can be moved, suppressed, cut, copied, pasted, selected; - add an undo/redo manager.
2022-06-01 17:38:08 +09:00
function webViewerSwitchAnnotationEditorMode(evt) {
[editor] Add an Ink editor - Approximate the drawn curve by a set of Bezier curves in using js code from https://github.com/soswow/fit-curves. The code has been slightly modified in order to make the linter happy.
2022-06-05 06:28:19 +09:00
PDFViewerApplication.pdfViewer.annotationEditorMode = evt.mode;
[edition] Add a FreeText editor (#14970) - add a basic UI to edit some text in a pdf; - an editor can be moved, suppressed, cut, copied, pasted, selected; - add an undo/redo manager.
2022-06-01 17:38:08 +09:00
}
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
function webViewerSwitchAnnotationEditorParams(evt) {
PDFViewerApplication.pdfViewer.annotationEditorParams = evt;
}
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
function webViewerPrint() {
Re-factor how printing is triggered in the default viewer This adds a new `PDFViewerApplication.triggerPrinting` method, which takes care of checking that printing is actually supported before calling `window.print`, to remove the need to duplicate that code in multiple places. Also, removes the `PDFViewerApplication.printing` getter since it's not really necessary any more.
2020-09-30 22:02:11 +09:00
PDFViewerApplication.triggerPrinting();
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
}
Support file save triggered from the Firefox integrated version. Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1659753 This allows Firefox trigger a "save" event from ctrl/cmd+s or the "Save Page As" context menu, which in turn lets pdf.js generate a new PDF if there is form data to save. I also now use `sourceEventType` on downloads so Firefox can determine if it should launch the "open with" dialog or "save as" dialog.
2020-08-20 04:19:59 +09:00
function webViewerDownload() {
Remove the `sourceEventType` from the viewer (bug 1757771 follow-up) After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
2022-02-19 19:47:24 +09:00
PDFViewerApplication.downloadOrSave();
Support file save triggered from the Firefox integrated version. Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1659753 This allows Firefox trigger a "save" event from ctrl/cmd+s or the "Save Page As" context menu, which in turn lets pdf.js generate a new PDF if there is form data to save. I also now use `sourceEventType` on downloads so Firefox can determine if it should launch the "open with" dialog or "save as" dialog.
2020-08-20 04:19:59 +09:00
}
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
function webViewerFirstPage() {
Remove a couple of unnecessary `pdfDocument` checks in `web/app.js` These functions invoke the `PDFViewer.currentPageNumber` setter, which already checks that a `pdfDocument` is currently active. Also, given that they're event handlers for the First/Last-page buttons (in the SecondaryToolbar) they can't be invoked before the viewer has been fully initalized.
2023-02-05 06:17:53 +09:00
PDFViewerApplication.page = 1;
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
}
function webViewerLastPage() {
Remove a couple of unnecessary `pdfDocument` checks in `web/app.js` These functions invoke the `PDFViewer.currentPageNumber` setter, which already checks that a `pdfDocument` is currently active. Also, given that they're event handlers for the First/Last-page buttons (in the SecondaryToolbar) they can't be invoked before the viewer has been fully initalized.
2023-02-05 06:17:53 +09:00
PDFViewerApplication.page = PDFViewerApplication.pagesCount;
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
}
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
function webViewerNextPage() {
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-16 02:45:12 +09:00
PDFViewerApplication.pdfViewer.nextPage();
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
}
function webViewerPreviousPage() {
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-16 02:45:12 +09:00
PDFViewerApplication.pdfViewer.previousPage();
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
}
function webViewerZoomIn() {
PDFViewerApplication.zoomIn();
}
function webViewerZoomOut() {
PDFViewerApplication.zoomOut();
}
[Firefox] Re-factor the 'zoomreset' message handling in the viewer (PR 10652 follow-up) Given that this special-case only matters for the Firefox PDF viewer, it's probably better to just move it into `firefoxcom.js` instead to reduce unnecessary confusion.
2019-07-17 18:59:56 +09:00
function webViewerZoomReset() {
PDFViewerApplication.zoomReset();
Prepare the `MOZCENTRAL` viewer for receiving zoom events from the browser UI (bug 786674, bug 1177385) This lays the necessary foundation for handling zoom events originating within the browser itself, rather than in the viewer. Please note that this will also require a follow-up patch to `mozilla-central`, such that the viewer is actually notified when zooming occurs.
2019-03-19 18:45:27 +09:00
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerPageNumberChanged(evt) {
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const pdfViewer = PDFViewerApplication.pdfViewer;
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824) Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit. The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`. The other changes are: - Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds. - Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages. - Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter. - Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
// Note that for `<input type="number">` HTML elements, an empty string will
// be returned for non-number inputs; hence we simply do nothing in that case.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (evt.value !== "") {
Also update the browser history when the user *manually* change pages using the pageNumber-input (PR 12493 follow-up) This patch addresses a review comment, which pointed out that we should *also* handle the pageNumber-input, from PR 12493. Given that a user *manually* changing pages using the pageNumber-input, on the toolbar, could be regarded as a pretty strong indication of user-intent w.r.t. navigation in the document, hence I suppose that updating the browser history in this case as well probably won't hurt.
2020-10-31 18:17:28 +09:00
PDFViewerApplication.pdfLinkService.goToPage(evt.value);
Attempt to tweak the error messages, in `BaseViewer`, for invalid pageNumbers/pageLabels (bug 1505824) Rather than closing [bug 1505824](https://bugzilla.mozilla.org/show_bug.cgi?id=1505824) as WONTFIX (which is my preferred solution), given how *minor* this "problem" is, it's still possible to adjust the error messages a bit. The main point here, which is relevant even if the changes in `BaseViewer` are ultimately rejected during review, is that we'll no longer attempt to call `BaseViewer.currentPageLabel` with an empty string from `webViewerPageNumberChanged` in `app.js`. The other changes are: - Stop printing an error in `BaseViewer._setCurrentPageNumber`, and have it return a boolean indicating if the page is within bounds. - Have the `BaseViewer.{currentPageNumber, currentPageLabel}` setters print their own errors for invalid pages. - Have the `BaseViewer.currentPageLabel` setter no longer depend, indirectly, on the `BaseViewer.currentPageNumber` setter. - Improve a couple of other error messages.
2018-11-15 00:16:09 +09:00
}
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
// Ensure that the page number input displays the correct value, even if the
// value entered by the user was invalid (e.g. a floating point number).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
evt.value !== pdfViewer.currentPageNumber.toString() &&
evt.value !== pdfViewer.currentPageLabel
) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.toolbar?.setPageNumber(
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
pdfViewer.currentPageNumber,
pdfViewer.currentPageLabel
);
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
}
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerScaleChanged(evt) {
PDFViewerApplication.pdfViewer.currentScaleValue = evt.value;
Refactor toolbar (and secondary toolbar).
2016-11-19 03:50:29 +09:00
}
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
function webViewerRotateCw() {
PDFViewerApplication.rotatePages(90);
}
function webViewerRotateCcw() {
PDFViewerApplication.rotatePages(-90);
}
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
function webViewerOptionalContentConfig(evt) {
PDFViewerApplication.pdfViewer.optionalContentConfigPromise = evt.promise;
}
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
function webViewerSwitchScrollMode(evt) {
Replace `setScrollMode`/`setSpreadMode` methods with getters/setters Since all the other viewer methods use the getter/setter pattern, e.g. for setting page/scale/rotation, the way that the Scroll/Spread modes are set thus stands out. For consistency, this really ought to use the same pattern as the rest of the `BaseViewer`. (To avoid breaking third-party implementations, the old methods are kept around as aliases.)
2018-06-29 22:07:42 +09:00
PDFViewerApplication.pdfViewer.scrollMode = evt.mode;
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
}
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
function webViewerSwitchSpreadMode(evt) {
Replace `setScrollMode`/`setSpreadMode` methods with getters/setters Since all the other viewer methods use the getter/setter pattern, e.g. for setting page/scale/rotation, the way that the Scroll/Spread modes are set thus stands out. For consistency, this really ought to use the same pattern as the rest of the `BaseViewer`. (To avoid breaking third-party implementations, the old methods are kept around as aliases.)
2018-06-29 22:07:42 +09:00
PDFViewerApplication.pdfViewer.spreadMode = evt.mode;
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
}
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
function webViewerDocumentProperties() {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.pdfDocumentProperties?.open();
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerFindFromUrlHash(evt) {
[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-03 23:03:51 +09:00
PDFViewerApplication.eventBus.dispatch("find", {
source: evt.source,
type: "",
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
query: evt.query,
phraseSearch: evt.phraseSearch,
Added multiple term search functionality (with default phrase search)
2016-05-26 22:24:58 +09:00
caseSensitive: false,
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
entireWord: false,
Added multiple term search functionality (with default phrase search)
2016-05-26 22:24:58 +09:00
highlightAll: true,
Fix inconsistent spacing and trailing commas in objects in `web/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. *Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/web/pdf_thumbnail_view.js b/web/pdf_thumbnail_view.js index 002dbf29..1de4e530 100644 --- a/web/pdf_thumbnail_view.js +++ b/web/pdf_thumbnail_view.js @@ -420,8 +420,8 @@ var PDFThumbnailView = (function PDFThumbnailViewClosure() { setPageLabel: function PDFThumbnailView_setPageLabel(label) { this.pageLabel = (typeof label === 'string' ? label : null); - this.l10n.get('thumb_page_title', { page: this.pageId, }, 'Page {{page}}'). - then((msg) => { + this.l10n.get('thumb_page_title', { page: this.pageId, }, + 'Page {{page}}').then((msg) => { this.anchor.title = msg; }); diff --git a/web/secondary_toolbar.js b/web/secondary_toolbar.js index 160e0410..6495fc5e 100644 --- a/web/secondary_toolbar.js +++ b/web/secondary_toolbar.js @@ -65,7 +65,8 @@ class SecondaryToolbar { { element: options.printButton, eventName: 'print', close: true, }, { element: options.downloadButton, eventName: 'download', close: true, }, { element: options.viewBookmarkButton, eventName: null, close: true, }, - { element: options.firstPageButton, eventName: 'firstpage', close: true, }, + { element: options.firstPageButton, eventName: 'firstpage', + close: true, }, { element: options.lastPageButton, eventName: 'lastpage', close: true, }, { element: options.pageRotateCwButton, eventName: 'rotatecw', close: false, }, @@ -76,7 +77,7 @@ class SecondaryToolbar { { element: options.cursorHandToolButton, eventName: 'switchcursortool', eventDetails: { tool: CursorTool.HAND, }, close: true, }, { element: options.documentPropertiesButton, - eventName: 'documentproperties', close: true, } + eventName: 'documentproperties', close: true, }, ]; this.items = { firstPage: options.firstPageButton, ```
2017-06-01 19:46:12 +09:00
findPrevious: false,
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
matchDiacritics: true,
Added multiple term search functionality (with default phrase search)
2016-05-26 22:24:58 +09:00
});
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
function webViewerUpdateFindMatchesCount({ matchesCount }) {
Replace callbacks for updating the UI with dispatching events on the event bus This makes it more similar to how other components update the viewer UI and avoids the need to have extra member variables and checks.
2018-09-22 03:00:58 +09:00
if (PDFViewerApplication.supportsIntegratedFind) {
PDFViewerApplication.externalServices.updateFindMatchesCount(matchesCount);
} else {
PDFViewerApplication.findBar.updateResultsCount(matchesCount);
}
}
Return the query with the findcontrols
2020-08-20 17:28:02 +09:00
function webViewerUpdateFindControlState({
state,
previous,
matchesCount,
rawQuery,
}) {
Replace callbacks for updating the UI with dispatching events on the event bus This makes it more similar to how other components update the viewer UI and avoids the need to have extra member variables and checks.
2018-09-22 03:00:58 +09:00
if (PDFViewerApplication.supportsIntegratedFind) {
PDFViewerApplication.externalServices.updateFindControlState({
result: state,
findPrevious: previous,
matchesCount,
Return the query with the findcontrols
2020-08-20 17:28:02 +09:00
rawQuery,
Replace callbacks for updating the UI with dispatching events on the event bus This makes it more similar to how other components update the viewer UI and avoids the need to have extra member variables and checks.
2018-09-22 03:00:58 +09:00
});
} else {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.findBar?.updateUIState(state, previous, matchesCount);
Replace callbacks for updating the UI with dispatching events on the event bus This makes it more similar to how other components update the viewer UI and avoids the need to have extra member variables and checks.
2018-09-22 03:00:58 +09:00
}
}
ES6-ify the code in `web/app.js` and `web/viewer.js` The changes consist mostly of changing `var` to `let`/`const`, and using shorthand method signatures.
2017-06-29 19:14:26 +09:00
function webViewerScaleChanging(evt) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.toolbar?.setPageScale(evt.presetValue, evt.scale);
Consolidate updating of various Toolbar state (e.g. page and scale) in one method in `PDFViewerApplication` With the changes in PR 7289, we no longer dispatch a 'pagechanging' event on load. Since most PDF documents open on the first page, this means that the `previous` and `firstPage` buttons are no longer correctly disabled. To avoid this, this patch moves the code that updates various UI toolbar state into one method, which is then called on document initialization and from the various existing event handling functions.
2016-06-27 19:32:28 +09:00
Remove unused globals and updateViewarea function from viewer.js
2015-07-23 23:02:39 +09:00
PDFViewerApplication.pdfViewer.update();
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Use Tango Public Domain icons and add some small tweaks to viewer.js
2011-07-30 01:17:04 +09:00
Slightly refactor the pages rotation handling code in the viewer This changes both `PDFViewer` and `PDFThumbnailViewer` to return early in the `pagesRotation` setters if the rotation doesn't change. It also fixes an existing issue, in `PDFViewer`, that would cause errors if the rotation changes *before* the scale has been set to a non-default value. Finally, in preparation for subsequent patches, it also refactors the rotation code in `web/app.js` to update the thumbnails and trigger rendering with the new `rotationchanging` event.
2017-08-19 21:23:40 +09:00
function webViewerRotationChanging(evt) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.pdfThumbnailViewer) {
PDFViewerApplication.pdfThumbnailViewer.pagesRotation = evt.pagesRotation;
}
Slightly refactor the pages rotation handling code in the viewer This changes both `PDFViewer` and `PDFThumbnailViewer` to return early in the `pagesRotation` setters if the rotation doesn't change. It also fixes an existing issue, in `PDFViewer`, that would cause errors if the rotation changes *before* the scale has been set to a non-default value. Finally, in preparation for subsequent patches, it also refactors the rotation code in `web/app.js` to update the thumbnails and trigger rendering with the new `rotationchanging` event.
2017-08-19 21:23:40 +09:00
PDFViewerApplication.forceRendering();
// Ensure that the active page doesn't change during rotation.
PDFViewerApplication.pdfViewer.currentPageNumber = evt.pageNumber;
}
Update all `BaseViewer.getPageView`/`PDFThumbnailViewer.getThumbnail` call-sites, in `web/app.js`, to check the returned value properly Given how those are used, there *should* not be any situation in which e.g. `undefined` is ever returned. However, actually checking that the pageView/thumbnail is defined cannot hurt. Also, re-factor `webViewerPageRendered` slightly since the `pageView` is no longer unconditionally necessary after the previous patches; note in particular that the thumbnails will only be updated when the sidebar *and* the thumbnailView is visible. Finally, fixes a bug in `webViewerPageChanging` whereby an empty string would not be treated as a valid pageLabel and instead be replaced by `null`.
2020-09-23 22:38:54 +09:00
function webViewerPageChanging({ pageNumber, pageLabel }) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.toolbar?.setPageNumber(pageNumber, pageLabel);
PDFViewerApplication.secondaryToolbar?.setPageNumber(pageNumber);
Remove the `previousPageNumber` parameter from the `pagechanging`/pagechange` events, and stop dispatching the events if the input is out of bounds This patch attempts to cleanup a couple of things: - Remove the `previousPageNumber` paramater. Prior to PR 7289, when the events were dispatched even when the active page didn't change, it made sense to be able to detect that in an event listener. However, now that's no longer the case, and furthermore other similar events (e.g. `scalechanging`/`scalechange`) don't include information about the previous state. - Don't dispatch the events when the value passed to `set currentPageNumber` is out of bounds. Given that the active page doesn't change in this case, again similar to PR 7289, I don't think that the events should actually be dispatched in this case. - Ensure that the value passed to `set currentPageNumber` is actually an integer, to avoid any issues (note how e.g. `set currentScale` has similar validation code). Given that these changes could possibly affect the PDF.js `mochitest` integration tests in mozilla-central, in particular https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/test/browser_pdfjs_navigation.js, I ran the tests locally with this patch applied to ensure that they still pass.
2016-07-22 22:32:14 +09:00
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.pdfSidebar?.visibleView === SidebarView.THUMBS) {
PDFViewerApplication.pdfThumbnailViewer?.scrollThumbnailIntoView(
pageNumber
);
Add selection ring around thumbnails.
2012-04-14 06:14:05 +09:00
}
Only display the pageNumber-loadingIcon when rendering is currently running *This makes the same kind of changes as in the previous patch, but for the pageNumber-loadingIcon in the main toolbar.* To display the pageNumber-loadingIcon when rendering starts, if the page is the most visible one, we'll utilize the existing "pagerender" event. To toggle the pageNumber-loadingIcon as the user moves through the document we'll now instead utilize the "pagechanging" event, which should actually be slightly more efficient overall[1]. Note how we'd, in the old code, only consider the most visible page anyway when toggling the pageNumber-loadingIcon. --- [1] Even in a PDF document as relatively short/simple as `tracemonkey.pdf`, scrolling through the entire document can easily trigger the "updateviewarea" event more than a thousand times.
2022-12-26 23:00:30 +09:00
// Show/hide the loading indicator in the page number input element.
const currentPage = PDFViewerApplication.pdfViewer.getPageView(
/* index = */ pageNumber - 1
);
PDFViewerApplication.toolbar?.updateLoadingIndicatorState(
currentPage?.renderingState === RenderingStates.RUNNING
);
Adds EventBus.
2016-04-26 07:57:15 +09:00
}
Zooming control
2011-09-03 10:16:52 +09:00
Refresh the viewer if the window resolution changes (bug 1784850) *Please note:* This probably fixes bug 1784850, however I don't have the necessary hardware to reproduce the situation described in https://bugzilla.mozilla.org/show_bug.cgi?id=1784850#c0 Unfortunately it doesn't, as far as I can tell, appear possible to detect *all* resolution changes with a single media query. Instead we have to update it, and its listener, on every resolution change as outlined in [this MDN example](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio#monitoring_screen_resolution_or_zoom_level_changes).
2022-08-15 23:21:58 +09:00
function webViewerResolutionChange(evt) {
PDFViewerApplication.pdfViewer.refresh();
}
Attempt to ignore mouse wheel zooming during tab switches (bug 1503412) This patch re-factors, and extends, the already existing `zoomDisabledTimeout` used during mouse wheel zooming. Unfortunately I haven't got the required hardware to actually test this patch, but there's a decent chance that it will fix, or at least reduce, the problems reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1503412.
2018-12-12 21:46:47 +09:00
function webViewerVisibilityChange(evt) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (document.visibilityState === "visible") {
Attempt to ignore mouse wheel zooming during tab switches (bug 1503412) This patch re-factors, and extends, the already existing `zoomDisabledTimeout` used during mouse wheel zooming. Unfortunately I haven't got the required hardware to actually test this patch, but there's a decent chance that it will fix, or at least reduce, the problems reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1503412.
2018-12-12 21:46:47 +09:00
// Ignore mouse wheel zooming during tab switches (bug 1503412).
setZoomDisabledTimeout();
}
}
let zoomDisabledTimeout = null;
function setZoomDisabledTimeout() {
if (zoomDisabledTimeout) {
clearTimeout(zoomDisabledTimeout);
}
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
zoomDisabledTimeout = setTimeout(function () {
Attempt to ignore mouse wheel zooming during tab switches (bug 1503412) This patch re-factors, and extends, the already existing `zoomDisabledTimeout` used during mouse wheel zooming. Unfortunately I haven't got the required hardware to actually test this patch, but there's a decent chance that it will fix, or at least reduce, the problems reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1503412.
2018-12-12 21:46:47 +09:00
zoomDisabledTimeout = null;
}, WHEEL_ZOOM_DISABLED_TIMEOUT);
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
function webViewerWheel(evt) {
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
const {
pdfViewer,
supportedMouseWheelZoomModifierKeys,
supportsPinchToZoom,
} = PDFViewerApplication;
Ensure that setting the `zoomDisabledTimeout` isn't skipped, regardless of the supported zoom keys, when handling mouse wheel events (PR 7097 follow-up) *Possible follow-up:* It probably wouldn't hurt to try and shorten the `supportedMouseWheelZoomModifierKeys` name a bit, but I'm not attempting that here since it'd also require updating `PdfStreamConverter.jsm` in mozilla-central in order to be consistent.
2019-07-24 00:36:45 +09:00
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
if (pdfViewer.isInPresentationMode) {
Simplified wheel processing.
2016-09-28 05:27:42 +09:00
return;
}
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
// Pinch-to-zoom on a trackpad maps to a wheel event with ctrlKey set to true
// https://developer.mozilla.org/en-US/docs/Web/API/WheelEvent#browser_compatibility
// Hence if ctrlKey is true but ctrl key hasn't been pressed then we can
// infer that we have a pinch-to-zoom.
Try to avoid to interpret wheel events as pinch-to-zoom ones (bug 1810800)
2023-01-25 02:35:15 +09:00
// But the ctrlKey could have been pressed outside of the browser window,
// hence we try to do some magic to guess if the scaleFactor is likely coming
// from a pinch-to-zoom or not.
// It is important that we query deltaMode before delta{X,Y}, so that
// Firefox doesn't switch to DOM_DELTA_PIXEL mode for compat with other
// browsers, see https://bugzilla.mozilla.org/show_bug.cgi?id=1392460.
const deltaMode = evt.deltaMode;
// The following formula is a bit strange but it comes from:
// https://searchfox.org/mozilla-central/rev/d62c4c4d5547064487006a1506287da394b64724/widget/InputData.cpp#618-626
let scaleFactor = Math.exp(-evt.deltaY / 100);
Fix pinch-to-zoom on mac for the Firefox builtin viewer In the mac case we don't want to care about the scaleFactor threshold because else if too big another move could start and then subsequent events aren't considered as wheel events. It isn't really ideal and at some point we'll need to find a way at least for the Firefox case to get the real events instead of the fake wheel ones.
2023-02-08 22:31:28 +09:00
const isBuiltInMac =
typeof PDFJSDev !== "undefined" &&
PDFJSDev.test("MOZCENTRAL") &&
FeatureTest.platform.isMac;
Try to avoid to interpret wheel events as pinch-to-zoom ones (bug 1810800)
2023-01-25 02:35:15 +09:00
const isPinchToZoom =
evt.ctrlKey &&
!PDFViewerApplication._isCtrlKeyDown &&
deltaMode === WheelEvent.DOM_DELTA_PIXEL &&
evt.deltaX === 0 &&
Fix pinch-to-zoom on mac for the Firefox builtin viewer In the mac case we don't want to care about the scaleFactor threshold because else if too big another move could start and then subsequent events aren't considered as wheel events. It isn't really ideal and at some point we'll need to find a way at least for the Firefox case to get the real events instead of the fake wheel ones.
2023-02-08 22:31:28 +09:00
(Math.abs(scaleFactor - 1) < 0.05 || isBuiltInMac) &&
Try to avoid to interpret wheel events as pinch-to-zoom ones (bug 1810800)
2023-01-25 02:35:15 +09:00
evt.deltaZ === 0;
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
isPinchToZoom ||
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
(evt.ctrlKey && supportedMouseWheelZoomModifierKeys.ctrlKey) ||
(evt.metaKey && supportedMouseWheelZoomModifierKeys.metaKey)
) {
Move the PresentationMode-specific scrollWheel code from PDFViewerApplication
2015-02-01 00:46:23 +09:00
// Only zoom the pages, not the entire viewer.
Disable zooming in Presentation Mode
2014-10-16 05:03:13 +09:00
evt.preventDefault();
Prevent the *entire* viewer from zooming, when quickly switching from scrolling to zooming using the mousewheel (PR 7097 followup) This is a regression from PR 7097. (Also, out of scope for this PR, but I think that a `setTimeout` value of `1000 ms` is too large. Switching from scrolling to zooming can fell sluggish, and give the impression that nothing happens.)
2016-04-08 04:03:04 +09:00
// NOTE: this check must be placed *after* preventDefault.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (zoomDisabledTimeout || document.visibilityState === "hidden") {
Prevent the *entire* viewer from zooming, when quickly switching from scrolling to zooming using the mousewheel (PR 7097 followup) This is a regression from PR 7097. (Also, out of scope for this PR, but I think that a `setTimeout` value of `1000 ms` is too large. Switching from scrolling to zooming can fell sluggish, and give the impression that nothing happens.)
2016-04-08 04:03:04 +09:00
return;
}
Zoom relative to cursor position via mouse wheel Before this patch, zooming in/out via the scroll wheel caused the page to be zoomed relative to the upper-left corner of the page, i.e. the upper-left corner of the page stays at a fixed position. After this patch, the page is zoomed relative to the cursor position, i.e. after zooming in/out, the part under the cursor 'has not moved'. This only applies when the page does not fit in the viewport, because pages smaller than the viewpoer are always centered.
2015-07-03 06:20:37 +09:00
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const previousScale = pdfViewer.currentScale;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
if (isPinchToZoom && supportsPinchToZoom) {
scaleFactor = PDFViewerApplication._accumulateFactor(
previousScale,
scaleFactor,
"_wheelUnusedFactor"
);
if (scaleFactor < 1) {
PDFViewerApplication.zoomOut(null, scaleFactor);
} else if (scaleFactor > 1) {
PDFViewerApplication.zoomIn(null, scaleFactor);
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
} else {
return;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
}
} else {
const delta = normalizeWheelEventDirection(evt);
Zoom relative to cursor position via mouse wheel Before this patch, zooming in/out via the scroll wheel caused the page to be zoomed relative to the upper-left corner of the page, i.e. the upper-left corner of the page stays at a fixed position. After this patch, the page is zoomed relative to the cursor position, i.e. after zooming in/out, the part under the cursor 'has not moved'. This only applies when the page does not fit in the viewport, because pages smaller than the viewpoer are always centered.
2015-07-03 06:20:37 +09:00
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
let ticks = 0;
if (
deltaMode === WheelEvent.DOM_DELTA_LINE ||
deltaMode === WheelEvent.DOM_DELTA_PAGE
) {
// For line-based devices, use one tick per event, because different
// OSs have different defaults for the number lines. But we generally
// want one "clicky" roll of the wheel (which produces one event) to
// adjust the zoom by one step.
if (Math.abs(delta) >= 1) {
ticks = Math.sign(delta);
} else {
// If we're getting fractional lines (I can't think of a scenario
// this might actually happen), be safe and use the accumulator.
ticks = PDFViewerApplication._accumulateTicks(
delta,
"_wheelUnusedTicks"
);
}
Bug 1392361 - Fix zooming sensitivity on macOS The original code would get a long sequence of miniscule "tick" values while pinch-zooming, and each tick value would cause a 1.1x zoom. So even the smallest pinch gesture on a trackpad would cause high amounts of zoom. This patch accumulates the wheel deltas until they reach an integer threshold (with a tweak of the scaling factor to make it feel more natural) at which point it triggers the zoom based on the integer component of the accumulated delta. The fractional part is retained in the accumulator.
2020-08-13 03:30:45 +09:00
} else {
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
// pixel-based devices
const PIXELS_PER_LINE_SCALE = 30;
Reduce duplication in the `accumulateWheelTicks`/`accumulateTouchTicks` methods (PR 15886 follow-up) It just occurred to me that we can reduce some duplication by having the, virtually identical, `accumulateWheelTicks`/`accumulateTouchTicks` methods use a common helper instead that takes advantage of [bracket notation](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics#bracket_notation).
2023-01-05 01:32:18 +09:00
ticks = PDFViewerApplication._accumulateTicks(
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
delta / PIXELS_PER_LINE_SCALE,
Reduce duplication in the `accumulateWheelTicks`/`accumulateTouchTicks` methods (PR 15886 follow-up) It just occurred to me that we can reduce some duplication by having the, virtually identical, `accumulateWheelTicks`/`accumulateTouchTicks` methods use a common helper instead that takes advantage of [bracket notation](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics#bracket_notation).
2023-01-05 01:32:18 +09:00
"_wheelUnusedTicks"
);
Bug 1392361 - Fix zooming sensitivity on macOS The original code would get a long sequence of miniscule "tick" values while pinch-zooming, and each tick value would cause a 1.1x zoom. So even the smallest pinch gesture on a trackpad would cause high amounts of zoom. This patch accumulates the wheel deltas until they reach an integer threshold (with a tweak of the scaling factor to make it feel more natural) at which point it triggers the zoom based on the integer component of the accumulated delta. The fractional part is retained in the accumulator.
2020-08-13 03:30:45 +09:00
}
Simplified wheel processing.
2016-09-28 05:27:42 +09:00
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
if (ticks < 0) {
PDFViewerApplication.zoomOut(-ticks);
} else if (ticks > 0) {
PDFViewerApplication.zoomIn(ticks);
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
} else {
return;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
}
Simplified wheel processing.
2016-09-28 05:27:42 +09:00
}
Zoom relative to cursor position via mouse wheel Before this patch, zooming in/out via the scroll wheel caused the page to be zoomed relative to the upper-left corner of the page, i.e. the upper-left corner of the page stays at a fixed position. After this patch, the page is zoomed relative to the cursor position, i.e. after zooming in/out, the part under the cursor 'has not moved'. This only applies when the page does not fit in the viewport, because pages smaller than the viewpoer are always centered.
2015-07-03 06:20:37 +09:00
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
// After scaling the page via zoomIn/zoomOut, the position of the upper-
// left corner is restored. When the mouse wheel is used, the position
// under the cursor should be restored instead.
PDFViewerApplication._centerAtPos(previousScale, evt.clientX, evt.clientY);
Disables zooming when the stream of events that don't have meta/ctrl keys active at the outset, for 1000ms
2016-04-08 01:48:46 +09:00
} else {
Attempt to ignore mouse wheel zooming during tab switches (bug 1503412) This patch re-factors, and extends, the already existing `zoomDisabledTimeout` used during mouse wheel zooming. Unfortunately I haven't got the required hardware to actually test this patch, but there's a decent chance that it will fix, or at least reduce, the problems reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1503412.
2018-12-12 21:46:47 +09:00
setZoomDisabledTimeout();
Dismiss native browser zoom, and use PDF.JS zoom instead
2012-06-08 04:27:26 +09:00
}
Implements mouse wheel behaviour for non-Firefox browsers
2014-01-29 04:52:25 +09:00
}
Bug 1643508 - Disable touch-based pinch zooming on pdf.js. Currently using a touchscreen with pdf.js doesn't work so well. In Firefox, with apz.allow_zooming = false (default on current release/beta), it does a reflow zoom which makes the UI elements bigger. And with apz.allow_zooming = true (default on current Firefox nightly), or in Chrome, it does a smooth pinch-zoom but that also scales up the entire UI. Neither of these is a particularly good experience, so this patch just disables any multi-touch gestures. Touch-based panning (which involves a single touch point) is left unaffected.
2020-08-13 04:09:42 +09:00
function webViewerTouchStart(evt) {
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
if (
PDFViewerApplication.pdfViewer.isInPresentationMode ||
evt.touches.length < 2
) {
return;
Bug 1643508 - Disable touch-based pinch zooming on pdf.js. Currently using a touchscreen with pdf.js doesn't work so well. In Firefox, with apz.allow_zooming = false (default on current release/beta), it does a reflow zoom which makes the UI elements bigger. And with apz.allow_zooming = true (default on current Firefox nightly), or in Chrome, it does a smooth pinch-zoom but that also scales up the entire UI. Neither of these is a particularly good experience, so this patch just disables any multi-touch gestures. Touch-based panning (which involves a single touch point) is left unaffected.
2020-08-13 04:09:42 +09:00
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
evt.preventDefault();
if (evt.touches.length !== 2) {
PDFViewerApplication._touchInfo = null;
return;
}
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
let [touch0, touch1] = evt.touches;
if (touch0.identifier > touch1.identifier) {
[touch0, touch1] = [touch1, touch0];
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
PDFViewerApplication._touchInfo = {
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
touch0X: touch0.pageX,
touch0Y: touch0.pageY,
touch1X: touch1.pageX,
touch1Y: touch1.pageY,
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
};
}
function webViewerTouchMove(evt) {
if (!PDFViewerApplication._touchInfo || evt.touches.length !== 2) {
return;
}
const { pdfViewer, _touchInfo, supportsPinchToZoom } = PDFViewerApplication;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
let [touch0, touch1] = evt.touches;
if (touch0.identifier > touch1.identifier) {
[touch0, touch1] = [touch1, touch0];
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
const { pageX: page0X, pageY: page0Y } = touch0;
const { pageX: page1X, pageY: page1Y } = touch1;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
const {
touch0X: pTouch0X,
touch0Y: pTouch0Y,
touch1X: pTouch1X,
touch1Y: pTouch1Y,
} = _touchInfo;
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
if (
Math.abs(pTouch0X - page0X) <= 1 &&
Math.abs(pTouch0Y - page0Y) <= 1 &&
Math.abs(pTouch1X - page1X) <= 1 &&
Math.abs(pTouch1Y - page1Y) <= 1
) {
// Touches are really too close and it's hard do some basic
// geometry in order to guess something.
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
return;
}
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
_touchInfo.touch0X = page0X;
_touchInfo.touch0Y = page0Y;
_touchInfo.touch1X = page1X;
_touchInfo.touch1Y = page1Y;
if (pTouch0X === page0X && pTouch0Y === page0Y) {
// First touch is fixed, if the vectors are collinear then we've a pinch.
const v1X = pTouch1X - page0X;
const v1Y = pTouch1Y - page0Y;
const v2X = page1X - page0X;
const v2Y = page1Y - page0Y;
const det = v1X * v2Y - v1Y * v2X;
// 0.02 is approximatively sin(0.15deg).
if (Math.abs(det) > 0.02 * Math.hypot(v1X, v1Y) * Math.hypot(v2X, v2Y)) {
return;
}
} else if (pTouch1X === page1X && pTouch1Y === page1Y) {
// Second touch is fixed, if the vectors are collinear then we've a pinch.
const v1X = pTouch0X - page1X;
const v1Y = pTouch0Y - page1Y;
const v2X = page0X - page1X;
const v2Y = page0Y - page1Y;
const det = v1X * v2Y - v1Y * v2X;
if (Math.abs(det) > 0.02 * Math.hypot(v1X, v1Y) * Math.hypot(v2X, v2Y)) {
return;
}
} else {
const diff0X = page0X - pTouch0X;
const diff1X = page1X - pTouch1X;
const diff0Y = page0Y - pTouch0Y;
const diff1Y = page1Y - pTouch1Y;
const dotProduct = diff0X * diff1X + diff0Y * diff1Y;
if (dotProduct >= 0) {
// The two touches go in almost the same direction.
return;
}
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
}
evt.preventDefault();
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
const distance = Math.hypot(page0X - page1X, page0Y - page1Y) || 1;
const pDistance = Math.hypot(pTouch0X - pTouch1X, pTouch0Y - pTouch1Y) || 1;
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
const previousScale = pdfViewer.currentScale;
if (supportsPinchToZoom) {
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
const newScaleFactor = PDFViewerApplication._accumulateFactor(
previousScale,
distance / pDistance,
"_touchUnusedFactor"
);
if (newScaleFactor < 1) {
PDFViewerApplication.zoomOut(null, newScaleFactor);
} else if (newScaleFactor > 1) {
PDFViewerApplication.zoomIn(null, newScaleFactor);
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
} else {
return;
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
}
} else {
const PIXELS_PER_LINE_SCALE = 30;
Reduce duplication in the `accumulateWheelTicks`/`accumulateTouchTicks` methods (PR 15886 follow-up) It just occurred to me that we can reduce some duplication by having the, virtually identical, `accumulateWheelTicks`/`accumulateTouchTicks` methods use a common helper instead that takes advantage of [bracket notation](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics#bracket_notation).
2023-01-05 01:32:18 +09:00
const ticks = PDFViewerApplication._accumulateTicks(
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
(distance - pDistance) / PIXELS_PER_LINE_SCALE,
Reduce duplication in the `accumulateWheelTicks`/`accumulateTouchTicks` methods (PR 15886 follow-up) It just occurred to me that we can reduce some duplication by having the, virtually identical, `accumulateWheelTicks`/`accumulateTouchTicks` methods use a common helper instead that takes advantage of [bracket notation](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Basics#bracket_notation).
2023-01-05 01:32:18 +09:00
"_touchUnusedTicks"
);
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
if (ticks < 0) {
PDFViewerApplication.zoomOut(-ticks);
} else if (ticks > 0) {
PDFViewerApplication.zoomIn(ticks);
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
} else {
return;
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
}
}
Add a `PDFViewerApplication` helper method to center the position after wheel/pinch-zooming This avoids having to repeat the same code twice, now that we support both wheel- and pinch-zooming.
2023-01-18 01:57:55 +09:00
PDFViewerApplication._centerAtPos(
previousScale,
(page0X + page1X) / 2,
(page0Y + page1Y) / 2
);
[api-minor] Add the pinch-to-zoom feature (bug 1677933)
2023-01-03 02:23:44 +09:00
}
function webViewerTouchEnd(evt) {
if (!PDFViewerApplication._touchInfo) {
return;
}
evt.preventDefault();
PDFViewerApplication._touchInfo = null;
PDFViewerApplication._touchUnusedTicks = 0;
Add support for smooth pinch-to-zoom on a trackpad (bug 1659492) - Scale factor is rounded to only scale by integer percent, hence the unused ticks are accumulated (like we already do for zoom with the mouse wheel). - Use the same thing for the pinch-to-zoom on a touchscreen: it led to slightly refactor the code because it happened to ignore a not so small scale which led to a not so smooth zooming.
2023-01-10 02:07:52 +09:00
PDFViewerApplication._touchUnusedFactor = 1;
Bug 1643508 - Disable touch-based pinch zooming on pdf.js. Currently using a touchscreen with pdf.js doesn't work so well. In Firefox, with apz.allow_zooming = false (default on current release/beta), it does a reflow zoom which makes the UI elements bigger. And with apz.allow_zooming = true (default on current Firefox nightly), or in Chrome, it does a smooth pinch-zoom but that also scales up the entire UI. Neither of these is a particularly good experience, so this patch just disables any multi-touch gestures. Touch-based panning (which involves a single touch point) is left unaffected.
2020-08-13 04:09:42 +09:00
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
function webViewerClick(evt) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (!PDFViewerApplication.secondaryToolbar?.isOpen) {
Removes circular dependency of secondary toolbar on app.js.
2016-04-29 05:04:09 +09:00
return;
}
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const appConfig = PDFViewerApplication.appConfig;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
PDFViewerApplication.pdfViewer.containsElement(evt.target) ||
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
(appConfig.toolbar?.container.contains(evt.target) &&
evt.target !== appConfig.secondaryToolbar?.toggleButton)
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
Convert the secondary toolbar to a class
2016-05-11 08:31:03 +09:00
PDFViewerApplication.secondaryToolbar.close();
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
}
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
function webViewerKeyUp(evt) {
// evt.ctrlKey is false hence we use evt.key.
if (evt.key === "Control") {
PDFViewerApplication._isCtrlKeyDown = false;
}
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
function webViewerKeyDown(evt) {
Fix pinch-to-zoom on a macbook trackpad (bug 1809080)
2023-01-09 18:58:22 +09:00
PDFViewerApplication._isCtrlKeyDown = evt.key === "Control";
Convert the overlay manager to ES6 syntax
2017-05-26 21:52:23 +09:00
if (PDFViewerApplication.overlayManager.active) {
Improved password prompt
2013-09-25 00:46:54 +09:00
return;
}
[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-03 23:03:51 +09:00
const { eventBus, pdfViewer } = PDFViewerApplication;
const isViewerInPresentationMode = pdfViewer.isInPresentationMode;
Improved password prompt
2013-09-25 00:46:54 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
let handled = false,
ensureViewerFocused = false;
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const cmd =
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
(evt.ctrlKey ? 1 : 0) |
(evt.altKey ? 2 : 0) |
(evt.shiftKey ? 4 : 0) |
(evt.metaKey ? 8 : 0);
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
// First, handle the key bindings that are independent whether an input
// control is selected or not.
Adds optional Shift for zoom keybindings
2013-03-12 01:04:43 +09:00
if (cmd === 1 || cmd === 8 || cmd === 5 || cmd === 12) {
// either CTRL or META key with optional SHIFT.
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
switch (evt.keyCode) {
Removing code duplication
2013-07-18 20:37:55 +09:00
case 70: // f
Don't trigger searching, in the `GENERIC` viewer, when <kbd>Shift</kbd> is used together with the regular keyboard shortcut (issue 12421) Please note that this change won't affect the Firefox built-in PDF Viewer, since it uses the native browser findbar. However, it brings the `GENERIC` viewer inline with how searching is normally triggered in browsers. Note that in Firefox searching is only triggered by <kbd>Ctrl</kbd>+<kbd>F</kbd> (or <kbd>command</kbd>+<kbd>F</kbd> on Mac), but <kbd>Shift</kbd> isn't used; see https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_search Furthermore, looking at the "Miscellaneous" section of https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#firefox:mac:fx81 the <kbd>command</kbd>+<kbd>Shift</kbd>+<kbd>F</kbd> shortcut is even reserved for the "Toggle Full Screen" functionality on Mac.
2020-09-29 17:37:33 +09:00
if (!PDFViewerApplication.supportsIntegratedFind && !evt.shiftKey) {
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.findBar?.open();
Add support for firefox integrated find.
2012-10-06 05:59:13 +09:00
handled = true;
}
Julian's html-search-bar work
2012-09-12 01:30:44 +09:00
break;
Removing code duplication
2013-07-18 20:37:55 +09:00
case 71: // g
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
if (!PDFViewerApplication.supportsIntegratedFind) {
[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-03 23:03:51 +09:00
const { state } = PDFViewerApplication.findController;
if (state) {
[GENERIC viewer] Simplify the keyboard find-again state building By using modern JavaScript features, we can ever so slightly reduce the amount of code needed here.
2023-02-05 07:10:41 +09:00
const newState = {
[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-03 23:03:51 +09:00
source: window,
type: "again",
Fix inconsistent spacing and trailing commas in objects in `web/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. *Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/web/pdf_thumbnail_view.js b/web/pdf_thumbnail_view.js index 002dbf29..1de4e530 100644 --- a/web/pdf_thumbnail_view.js +++ b/web/pdf_thumbnail_view.js @@ -420,8 +420,8 @@ var PDFThumbnailView = (function PDFThumbnailViewClosure() { setPageLabel: function PDFThumbnailView_setPageLabel(label) { this.pageLabel = (typeof label === 'string' ? label : null); - this.l10n.get('thumb_page_title', { page: this.pageId, }, 'Page {{page}}'). - then((msg) => { + this.l10n.get('thumb_page_title', { page: this.pageId, }, + 'Page {{page}}').then((msg) => { this.anchor.title = msg; }); diff --git a/web/secondary_toolbar.js b/web/secondary_toolbar.js index 160e0410..6495fc5e 100644 --- a/web/secondary_toolbar.js +++ b/web/secondary_toolbar.js @@ -65,7 +65,8 @@ class SecondaryToolbar { { element: options.printButton, eventName: 'print', close: true, }, { element: options.downloadButton, eventName: 'download', close: true, }, { element: options.viewBookmarkButton, eventName: null, close: true, }, - { element: options.firstPageButton, eventName: 'firstpage', close: true, }, + { element: options.firstPageButton, eventName: 'firstpage', + close: true, }, { element: options.lastPageButton, eventName: 'lastpage', close: true, }, { element: options.pageRotateCwButton, eventName: 'rotatecw', close: false, }, @@ -76,7 +77,7 @@ class SecondaryToolbar { { element: options.cursorHandToolButton, eventName: 'switchcursortool', eventDetails: { tool: CursorTool.HAND, }, close: true, }, { element: options.documentPropertiesButton, - eventName: 'documentproperties', close: true, } + eventName: 'documentproperties', close: true, }, ]; this.items = { firstPage: options.firstPageButton, ```
2017-06-01 19:46:12 +09:00
findPrevious: cmd === 5 || cmd === 12,
[GENERIC viewer] Simplify the keyboard find-again state building By using modern JavaScript features, we can ever so slightly reduce the amount of code needed here.
2023-02-05 07:10:41 +09:00
};
eventBus.dispatch("find", { ...state, ...newState });
Refactors PDFFindBar and FirefoxCom find events.
2016-04-28 21:11:40 +09:00
}
Removing code duplication
2013-07-18 20:37:55 +09:00
handled = true;
}
break;
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
case 61: // FF/Mac '='
case 107: // FF '+' and '='
case 187: // Chrome '+'
Add German keyboard "+"-zoom.
2012-12-11 06:39:35 +09:00
case 171: // FF with German keyboard
Remove a couple of unnecessary PresentationMode-checks in `webViewerKeyDown` Given that the `PDFViewerApplication.{zoomIn, zoomOut}` methods already contain PresentationMode-checks, this is just unnecessary duplication.
2023-02-05 06:44:46 +09:00
PDFViewerApplication.zoomIn();
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
handled = true;
break;
Fix zoom out keyboard shortcut for mac.
2012-09-11 01:28:45 +09:00
case 173: // FF/Mac '-'
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
case 109: // FF '-'
case 189: // Chrome '-'
Remove a couple of unnecessary PresentationMode-checks in `webViewerKeyDown` Given that the `PDFViewerApplication.{zoomIn, zoomOut}` methods already contain PresentationMode-checks, this is just unnecessary duplication.
2023-02-05 06:44:46 +09:00
PDFViewerApplication.zoomOut();
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
handled = true;
break;
case 48: // '0'
Add reset of zoom level using CTRL + [Numpad 0] on Swedish keyboard
2012-12-12 07:59:33 +09:00
case 96: // '0' on Numpad of Swedish keyboard
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
if (!isViewerInPresentationMode) {
Disable zooming in Presentation Mode
2014-10-16 05:03:13 +09:00
// keeping it unhandled (to restore page zoom to 100%)
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
setTimeout(function () {
Disable zooming in Presentation Mode
2014-10-16 05:03:13 +09:00
// ... and resetting the scale after browser adjusts its scale
Prepare the `MOZCENTRAL` viewer for receiving zoom events from the browser UI (bug 786674, bug 1177385) This lays the necessary foundation for handling zoom events originating within the browser itself, rather than in the viewer. Please note that this will also require a follow-up patch to `mozilla-central`, such that the viewer is actually notified when zooming occurs.
2019-03-19 18:45:27 +09:00
PDFViewerApplication.zoomReset();
Disable zooming in Presentation Mode
2014-10-16 05:03:13 +09:00
});
handled = false;
}
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
break;
Make the keyboard shortcuts `Ctrl + Up/Down` behave as `Home/End` (issue 7852) It seems that for normal web pages, at least in Firefox, the keyboard shortcuts <kbd>Ctrl</kbd> + <kbd>Up</kbd>/<kbd>Down</kbd> are functionally equivalent to <kbd>Home</kbd>/<kbd>End</kbd>. This is obviously an edge-case, but can be easily implemented by using the same logic as we do for <kbd>Home</kbd>/<kbd>End</kbd>. Fixes 7852. *Please note:* I'm finding it slightly difficult to interpret issue 7852, and bug 1285719, since among other things: the title includes the word "reverse" with no other mention of it, and the STR makes reference to print preview which doesn't seem applicable to the PDF viewer. However, compared to regular web pages in Firefox, I think the behavior of this patch makes sense here.
2016-12-01 01:19:11 +09:00
case 38: // up arrow
if (isViewerInPresentationMode || PDFViewerApplication.page > 1) {
PDFViewerApplication.page = 1;
handled = true;
ensureViewerFocused = true;
}
break;
case 40: // down arrow
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
isViewerInPresentationMode ||
PDFViewerApplication.page < PDFViewerApplication.pagesCount
) {
Make the keyboard shortcuts `Ctrl + Up/Down` behave as `Home/End` (issue 7852) It seems that for normal web pages, at least in Firefox, the keyboard shortcuts <kbd>Ctrl</kbd> + <kbd>Up</kbd>/<kbd>Down</kbd> are functionally equivalent to <kbd>Home</kbd>/<kbd>End</kbd>. This is obviously an edge-case, but can be easily implemented by using the same logic as we do for <kbd>Home</kbd>/<kbd>End</kbd>. Fixes 7852. *Please note:* I'm finding it slightly difficult to interpret issue 7852, and bug 1285719, since among other things: the title includes the word "reverse" with no other mention of it, and the STR makes reference to print preview which doesn't seem applicable to the PDF viewer. However, compared to regular web pages in Firefox, I think the behavior of this patch makes sense here.
2016-12-01 01:19:11 +09:00
PDFViewerApplication.page = PDFViewerApplication.pagesCount;
handled = true;
ensureViewerFocused = true;
}
break;
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
}
}
Change the "download" keyboard shortcut (Ctrl+S) handling, in GENERIC/CHROME builds, to utilize the `EventBus` (issue 11657) This improves the consistency of the "download" handling, in the default viewer, such that the `Toolbar`/`SecondaryToolbar` buttons *and* the keyboard shortcut are now handled in the same way (using the `EventBus`). Given that the "download" keyboard shortcut handling is limited to GENERIC/CHROME builds and that the issue does raise a valid point about only being able to observe *some* downloads, these changes seem acceptable in this particular case. Finally the pre-processor condition is adjusted to *explicitly*, rather than implicitly, list the affected build targets. *Please note:* This patch should NOT be construed as carte blanche to simply convert all of the code in `webViewerKeyDown`, or elsewhere, to make use of the `EventBus` instead of direct function calls. Any further changes, along the lines in this patch, would need to be evaluated on a case-by-case basis to determine if they are actually wanted, given that many/most existing cases in `webViewerKeyDown` should already be *indirectly* observable through the `EventBus` instance.
2020-04-20 22:48:34 +09:00
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC || CHROME")) {
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
// CTRL or META without shift
if (cmd === 1 || cmd === 8) {
switch (evt.keyCode) {
case 83: // s
Change the "download" keyboard shortcut (Ctrl+S) handling, in GENERIC/CHROME builds, to utilize the `EventBus` (issue 11657) This improves the consistency of the "download" handling, in the default viewer, such that the `Toolbar`/`SecondaryToolbar` buttons *and* the keyboard shortcut are now handled in the same way (using the `EventBus`). Given that the "download" keyboard shortcut handling is limited to GENERIC/CHROME builds and that the issue does raise a valid point about only being able to observe *some* downloads, these changes seem acceptable in this particular case. Finally the pre-processor condition is adjusted to *explicitly*, rather than implicitly, list the affected build targets. *Please note:* This patch should NOT be construed as carte blanche to simply convert all of the code in `webViewerKeyDown`, or elsewhere, to make use of the `EventBus` instead of direct function calls. Any further changes, along the lines in this patch, would need to be evaluated on a case-by-case basis to determine if they are actually wanted, given that many/most existing cases in `webViewerKeyDown` should already be *indirectly* observable through the `EventBus` instance.
2020-04-20 22:48:34 +09:00
eventBus.dispatch("download", { source: window });
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
handled = true;
break;
Add a new "openfile" keyboard shortcut (Ctrl+O), in GENERIC builds Somewhat surprisingly, despite the GENERIC viewer implementing "openfile" support, there's never been a keyboard shortcut available. Similar to the previous patch, this utilizes the `EventBus` for consistency with the `Toolbar`/`SecondaryToolbar` buttons. *Please note:* This patch should NOT be construed as carte blanche to simply convert all of the code in `webViewerKeyDown`, or elsewhere, to make use of the `EventBus` instead of direct function calls. Any further changes, along the lines in this patch, would need to be evaluated on a case-by-case basis to determine if they are actually wanted, given that many/most existing cases in `webViewerKeyDown` should already be *indirectly* observable through the `EventBus` instance.
2020-04-20 22:55:02 +09:00
case 79: // o
if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
eventBus.dispatch("openfile", { source: window });
handled = true;
}
break;
Replaces all preprocessor directives with PDFJSDev calls.
2016-10-15 00:57:53 +09:00
}
Ctrl/cmd + S = save PDF instead of viewer.html
2014-02-28 00:08:43 +09:00
}
}
Presentation mode shortcut implementation
2013-07-18 23:28:06 +09:00
// CTRL+ALT or Option+Command
if (cmd === 3 || cmd === 10) {
switch (evt.keyCode) {
case 80: // p
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
PDFViewerApplication.requestPresentationMode();
Presentation mode shortcut implementation
2013-07-18 23:28:06 +09:00
handled = true;
Add some telemetry to know how often the buttons in the secondary toolbar are used (bug 1789883)
2022-09-09 02:23:41 +09:00
PDFViewerApplication.externalServices.reportTelemetry({
type: "buttons",
data: { id: "presentationModeKeyboard" },
});
Presentation mode shortcut implementation
2013-07-18 23:28:06 +09:00
break;
Add shortcut for goto page
2013-11-12 13:47:03 +09:00
case 71: // g
// focuses input#pageNumber field
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.appConfig.toolbar) {
PDFViewerApplication.appConfig.toolbar.pageNumber.select();
handled = true;
}
Add shortcut for goto page
2013-11-12 13:47:03 +09:00
break;
Presentation mode shortcut implementation
2013-07-18 23:28:06 +09:00
}
}
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
if (handled) {
Make the keyboard shortcuts `Ctrl + Up/Down` behave as `Home/End` (issue 7852) It seems that for normal web pages, at least in Firefox, the keyboard shortcuts <kbd>Ctrl</kbd> + <kbd>Up</kbd>/<kbd>Down</kbd> are functionally equivalent to <kbd>Home</kbd>/<kbd>End</kbd>. This is obviously an edge-case, but can be easily implemented by using the same logic as we do for <kbd>Home</kbd>/<kbd>End</kbd>. Fixes 7852. *Please note:* I'm finding it slightly difficult to interpret issue 7852, and bug 1285719, since among other things: the title includes the word "reverse" with no other mention of it, and the STR makes reference to print preview which doesn't seem applicable to the PDF viewer. However, compared to regular web pages in Firefox, I think the behavior of this patch makes sense here.
2016-12-01 01:19:11 +09:00
if (ensureViewerFocused && !isViewerInPresentationMode) {
pdfViewer.focus();
}
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
evt.preventDefault();
Fixes shortcuts steals from browser - Issue #979
2011-12-26 06:18:52 +09:00
return;
Really fix the keyboard handling
2012-04-12 07:47:11 +09:00
}
// Some shortcuts should not get handled if a control/input element
// is selected.
Fixed keydown event handling problem with shadow DOM. Editable elements in shadow DOMs can not be detected in old version.
2020-09-23 13:59:19 +09:00
const curElement = getActiveOrFocusedElement();
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-06 01:36:28 +09:00
const curElementTagName = curElement?.tagName.toUpperCase();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
curElementTagName === "INPUT" ||
curElementTagName === "TEXTAREA" ||
curElementTagName === "SELECT" ||
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-06 01:36:28 +09:00
curElement?.isContentEditable
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
Secondary toolbar
2013-09-05 06:48:31 +09:00
// Make sure that the secondary toolbar is closed when Escape is pressed.
Fix the linting errors, from the Prettier auto-formatting, that ESLint `--fix` couldn't handle This patch makes the follow changes: - Remove no longer necessary inline `// eslint-disable-...` comments. - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors. - Concatenate strings which now fit on just one line. - Fix comments that are now too long. - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 04:03:46 +09:00
if (evt.keyCode !== /* Esc = */ 27) {
Secondary toolbar
2013-09-05 06:48:31 +09:00
return;
}
Prevents key handling when the input/toolbar controls are focused
2012-10-02 06:32:02 +09:00
}
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
Fix the linting errors, from the Prettier auto-formatting, that ESLint `--fix` couldn't handle This patch makes the follow changes: - Remove no longer necessary inline `// eslint-disable-...` comments. - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors. - Concatenate strings which now fit on just one line. - Fix comments that are now too long. - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 04:03:46 +09:00
// No control key pressed at all.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (cmd === 0) {
let turnPage = 0,
turnOnlyIfPageFit = false;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
switch (evt.keyCode) {
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
case 38: // up arrow
case 33: // pg up
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
// vertical scrolling using arrow/pg keys
if (pdfViewer.isVerticalScrollbarEnabled) {
turnOnlyIfPageFit = true;
}
turnPage = -1;
break;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
case 8: // backspace
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
if (!isViewerInPresentationMode) {
turnOnlyIfPageFit = true;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
}
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnPage = -1;
break;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
case 37: // left arrow
Horizontal scrolling using the left/right arrow keys - version 4
2012-12-14 05:10:21 +09:00
// horizontal scrolling using arrow keys
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
if (pdfViewer.isHorizontalScrollbarEnabled) {
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnOnlyIfPageFit = true;
Horizontal scrolling using the left/right arrow keys - version 4
2012-12-14 05:10:21 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
/* falls through */
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
case 75: // 'k'
case 80: // 'p'
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnPage = -1;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
break;
Squashing commits for the close findbar feature
2013-02-11 00:14:17 +09:00
case 27: // esc key
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
if (PDFViewerApplication.secondaryToolbar?.isOpen) {
Convert the secondary toolbar to a class
2016-05-11 08:31:03 +09:00
PDFViewerApplication.secondaryToolbar.close();
Secondary toolbar
2013-09-05 06:48:31 +09:00
handled = true;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
!PDFViewerApplication.supportsIntegratedFind &&
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.findBar?.opened
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
PDFViewerApplication.findBar.close();
Squashing commits for the close findbar feature
2013-02-11 00:14:17 +09:00
handled = true;
}
break;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
case 40: // down arrow
case 34: // pg down
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
// vertical scrolling using arrow/pg keys
if (pdfViewer.isVerticalScrollbarEnabled) {
turnOnlyIfPageFit = true;
}
turnPage = 1;
break;
case 13: // enter key
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
case 32: // spacebar
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
if (!isViewerInPresentationMode) {
turnOnlyIfPageFit = true;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
}
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnPage = 1;
break;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
case 39: // right arrow
Horizontal scrolling using the left/right arrow keys - version 4
2012-12-14 05:10:21 +09:00
// horizontal scrolling using arrow keys
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
if (pdfViewer.isHorizontalScrollbarEnabled) {
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnOnlyIfPageFit = true;
Horizontal scrolling using the left/right arrow keys - version 4
2012-12-14 05:10:21 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
/* falls through */
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
case 74: // 'j'
case 78: // 'n'
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
turnPage = 1;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
break;
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
case 36: // home
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
if (isViewerInPresentationMode || PDFViewerApplication.page > 1) {
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
PDFViewerApplication.page = 1;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
handled = true;
Reduce code duplication in the 'keydown' event handler in `viewer.js`, by re-factoring the code which ensures that the `viewerContainer` is focused
2015-07-23 19:25:19 +09:00
ensureViewerFocused = true;
Adds more presentation mode controls
2012-10-06 11:55:47 +09:00
}
break;
case 35: // end
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
isViewerInPresentationMode ||
PDFViewerApplication.page < PDFViewerApplication.pagesCount
) {
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
PDFViewerApplication.page = PDFViewerApplication.pagesCount;
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
handled = true;
Reduce code duplication in the 'keydown' event handler in `viewer.js`, by re-factoring the code which ensures that the `viewerContainer` is focused
2015-07-23 19:25:19 +09:00
ensureViewerFocused = true;
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
}
break;
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
case 83: // 's'
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.pdfCursorTools?.switchTool(CursorTool.SELECT);
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
break;
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
case 72: // 'h'
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.pdfCursorTools?.switchTool(CursorTool.HAND);
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
break;
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
case 82: // 'r'
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
PDFViewerApplication.rotatePages(90);
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
break;
Add keyboard shortcut to toggle sidebar
2018-12-16 15:29:29 +09:00
case 115: // F4
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
PDFViewerApplication.pdfSidebar?.toggle();
Add keyboard shortcut to toggle sidebar
2018-12-16 15:29:29 +09:00
break;
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
}
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
turnPage !== 0 &&
(!turnOnlyIfPageFit || pdfViewer.currentScaleValue === "page-fit")
) {
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
if (turnPage > 0) {
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-16 02:45:12 +09:00
pdfViewer.nextPage();
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
} else {
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-16 02:45:12 +09:00
pdfViewer.previousPage();
Modify key events for horizontal scrolling Specifically, when there is no vertical scrollbar, let up, down, page up, and page down all trigger moving to the next or previous page.
2018-05-15 12:10:32 +09:00
}
handled = true;
}
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
}
Fix the linting errors, from the Prettier auto-formatting, that ESLint `--fix` couldn't handle This patch makes the follow changes: - Remove no longer necessary inline `// eslint-disable-...` comments. - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors. - Concatenate strings which now fit on just one line. - Fix comments that are now too long. - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 04:03:46 +09:00
// shift-key
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (cmd === 4) {
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
switch (evt.keyCode) {
Added enter key functionality for presentation mode
2018-01-05 03:54:19 +09:00
case 13: // enter key
Enable changing page using Shift+Spacebar in presentation mode
2013-06-27 05:25:47 +09:00
case 32: // spacebar
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
!isViewerInPresentationMode &&
pdfViewer.currentScaleValue !== "page-fit"
) {
Enable changing page using Shift+Spacebar in presentation mode
2013-06-27 05:25:47 +09:00
break;
}
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 19:48:18 +09:00
pdfViewer.previousPage();
Enable changing page using Shift+Spacebar in presentation mode
2013-06-27 05:25:47 +09:00
handled = true;
break;
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
case 82: // 'r'
Renames and refactors PDFView to PDFViewerApplication.
2014-09-22 20:41:17 +09:00
PDFViewerApplication.rotatePages(-90);
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
break;
Fix keyboard mapping in viewer
2012-04-11 01:55:52 +09:00
}
Zooming control
2011-09-03 10:16:52 +09:00
}
Prevent default actions when zooming. Otherwise the browser performs a zoom of the entire page
2011-12-19 04:42:06 +09:00
Break dependencies between PresentationMode and other code, and add PresentationMode related utility methods to PDFViewer This patch: - Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons. - Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them. - Adds a utility function to `PDFViewerApplication` for requesting PresentationMode. - Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
2015-01-29 21:37:49 +09:00
if (!handled && !isViewerInPresentationMode) {
Fix scrolling using Shift+Spacebar in Firefox
2014-02-27 21:33:35 +09:00
// 33=Page Up 34=Page Down 35=End 36=Home
// 37=Left 38=Up 39=Right 40=Down
// 32=Spacebar
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
(evt.keyCode >= 33 && evt.keyCode <= 40) ||
(evt.keyCode === 32 && curElementTagName !== "BUTTON")
) {
Reduce code duplication in the 'keydown' event handler in `viewer.js`, by re-factoring the code which ensures that the `viewerContainer` is focused
2015-07-23 19:25:19 +09:00
ensureViewerFocused = true;
Fix scrolling using Shift+Spacebar in Firefox
2014-02-27 21:33:35 +09:00
}
}
Reduce code duplication in the 'keydown' event handler in `viewer.js`, by re-factoring the code which ensures that the `viewerContainer` is focused
2015-07-23 19:25:19 +09:00
if (ensureViewerFocused && !pdfViewer.containsElement(curElement)) {
// The page container is not focused, but a page navigation key has been
// pressed. Change the focus to the viewer container to make sure that
// navigation by keyboard works as expected.
pdfViewer.focus();
}
Prevent default actions when zooming. Otherwise the browser performs a zoom of the entire page
2011-12-19 04:42:06 +09:00
if (handled) {
evt.preventDefault();
}
Don't call `bindEvents()` until `PDFViewerApplication` has been initialized, and move binding of `window` event listeners to a helper method, to prevent errors if an event manages to arrive too soon With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions. Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
2016-12-09 00:28:40 +09:00
}
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
#12241 followup - move event listener to PDFViewerApplication.load
2020-08-22 01:53:39 +09:00
function beforeUnload(evt) {
evt.preventDefault();
evt.returnValue = "";
return false;
}
[Editor] Dispatch an event when some global states are changing - this way the context menu in Firefox can take into account what we have in the clipboard, if an editor is selected, ... - when the user will click on a context menu item, an action will be triggered, hence this patch adds what is required to handle it; - some tests will be added in the Firefox' patch.
2022-07-05 01:04:32 +09:00
function webViewerAnnotationEditorStatesChanged(data) {
PDFViewerApplication.externalServices.updateEditorStates(data);
}
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
/* Abstract factory for the print service. */
Enable the ESLint `prefer-const` rule in the `web/` directory Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2019-12-27 08:22:32 +09:00
const PDFPrintServiceFactory = {
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
instance: {
supportsPrinting: false,
Enable the `object-shorthand` ESLint rule in `web` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-28 19:02:42 +09:00
createPrintService() {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new Error("Not implemented: createPrintService");
Fix inconsistent spacing and trailing commas in objects in `web/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. *Please note:* This patch was created automatically, using the ESLint `--fix` command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/web/pdf_thumbnail_view.js b/web/pdf_thumbnail_view.js index 002dbf29..1de4e530 100644 --- a/web/pdf_thumbnail_view.js +++ b/web/pdf_thumbnail_view.js @@ -420,8 +420,8 @@ var PDFThumbnailView = (function PDFThumbnailViewClosure() { setPageLabel: function PDFThumbnailView_setPageLabel(label) { this.pageLabel = (typeof label === 'string' ? label : null); - this.l10n.get('thumb_page_title', { page: this.pageId, }, 'Page {{page}}'). - then((msg) => { + this.l10n.get('thumb_page_title', { page: this.pageId, }, + 'Page {{page}}').then((msg) => { this.anchor.title = msg; }); diff --git a/web/secondary_toolbar.js b/web/secondary_toolbar.js index 160e0410..6495fc5e 100644 --- a/web/secondary_toolbar.js +++ b/web/secondary_toolbar.js @@ -65,7 +65,8 @@ class SecondaryToolbar { { element: options.printButton, eventName: 'print', close: true, }, { element: options.downloadButton, eventName: 'download', close: true, }, { element: options.viewBookmarkButton, eventName: null, close: true, }, - { element: options.firstPageButton, eventName: 'firstpage', close: true, }, + { element: options.firstPageButton, eventName: 'firstpage', + close: true, }, { element: options.lastPageButton, eventName: 'lastpage', close: true, }, { element: options.pageRotateCwButton, eventName: 'rotatecw', close: false, }, @@ -76,7 +77,7 @@ class SecondaryToolbar { { element: options.cursorHandToolButton, eventName: 'switchcursortool', eventDetails: { tool: CursorTool.HAND, }, close: true, }, { element: options.documentPropertiesButton, - eventName: 'documentproperties', close: true, } + eventName: 'documentproperties', close: true, }, ]; this.items = { firstPage: options.firstPageButton, ```
2017-06-01 19:46:12 +09:00
},
},
Moves mozPrintCallback specific code to firefox_printservice.js
2016-10-07 06:46:30 +09:00
};
Convert the files in the `/web` folder to ES6 modules Note that as discussed on IRC, this makes the viewer slightly slower to load *only* in `gulp server` mode, however the difference seem slight enough that I think it will be fine.
2017-03-28 08:07:27 +09:00
export {
DefaultExternalServices,
PDFPrintServiceFactory,
Use ESLint to ensure that `export`s 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 23:37:44 +09:00
PDFViewerApplication,
Convert the files in the `/web` folder to ES6 modules Note that as discussed on IRC, this makes the viewer slightly slower to load *only* in `gulp server` mode, however the difference seem slight enough that I think it will be fine.
2017-03-28 08:07:27 +09:00
};
Reference in New Issue Copy Permalink