**Steps to reproduce:**
1. Open the viewer.
2. Show the sidebar, and switch to the "Pages" view if necessary.
3. Click on the "Add file" button.
4. Choose a password-protected PDF, e.g. the `issue6010_1.pdf` file, via the "File Upload" dialog opened by the browser.
5. Enter the password, i.e. `abc`, and press the <kbd>Enter</kbd> key.
**Expected result:**
That the new PDF document is merged into the existing one, without UI side-effects.
**Actual result:**
Merging works, *however* the "File Upload" dialog is re-opened.
---
It seems that when the passwordPrompt dialog closes, the <kbd>Enter</kbd> key press (from the input) is forwarded to the previously focused element which naturally is the "Add file" button.
*Note:* This doesn't seem (easily) possible to test, since the integration-tests directly populate the `viewsManagerAddFilePicker` and doesn't actually "click" on the `viewsManagerAddFileButton` first.
This branch isn't covered by any tests, and looking at the two existing call-sites we only ever pass in a `CanvasRenderingContext2D` interface to this function.
Based on the git history this branch was added in PR 3312, however as far as I can tell it doesn't actually appear to have been necessary even back then!?
Annotation-local attachments (those not in the catalog `/Names` tree) were
resolved through a dictionary cache that `Catalog.cleanup` clears, so their
content became unreachable once the idle cleanup had run.
Encode the reference of the embedded content in the attachment id and re-fetch
it from the xref on demand instead of caching the dictionary, so the content
stays reachable without anything having to survive cleanup.
It fixes a regression introduced by #21351.
Introduces a 'supportsDownloading' browser option (defaulting to false)
that lets embedders disable the save/download paths entirely. When
disabled:
- the toolbar and secondary-toolbar download buttons are hidden;
- PDFViewerApplication.{download,save,downloadOrSave} and the
"beforeunload" save prompt bail out early;
- the BaseDownloadManager helpers (download, downloadData,
openOrDownloadData) and the Firefox/generic _triggerDownload
implementations no-op.
Currently we only check LinkAnnotations with URLs, but completely ignore e.g. internal destinations, named actions, attachments, SetOCGState actions, JS actions, and ResetForm actions when testing if inferred links overlap any existing annotation.
This seems conceptually wrong, since it may easily break intended functionality by overlaying the *correct* DOM element with an inferred link (as was the case in issue 21458).
Firefox 154 no longer walks the prototype chain in the `Error.stack`
getter, so `BaseException`-derived instances return an empty string
rather than the prototype `Error`'s stack (see bug 1946559).
The lower BlueScale clamp from #21343 guarded foundry fonts via
`blueScale < DEFAULT_BLUE_SCALE`, but that lets a near-default value
(e.g. 0.037) with small zones get raised to `0.5 / maxZoneHeight`. On
macOS' Core Text rasterizer this collapses the overshooting glyphs, so
most text disappears (not reproducible on Linux/Windows).
A non-isolated transparency group must blend with its backdrop, but a group
containing a blend mode was forced onto a transparent intermediate canvas;
e.g. a /Multiply highlight then painted opaquely over the text behind it,
making that text invisible.
This makes setting a few Dictionary entries a little bit shorter, which shouldn't hurt.
(Part of this code isn't fully covered by tests, so it improves overall code coverage as well.)
For checkbox and radio button fields, the export value can differ from the
appearance-state name: the field's inheritable `Opt` array holds the real
export values (used for non-Latin text, or values shared between buttons).
We previously exposed the appearance-state name as the export value.
Given that the Promise returned by the `PDFDocument.prototype.getPage` method *always* resolves with a `Page` instance, checking that the page is defined isn't necessary; note 3a09329113/src/core/document.js (L1702-L1723)
Furthermore the `Page.prototype.collectAnnotationsByType` method is asynchronous, and thus it always returns a Promise, hence it's "pointless" to fallback to return an empty Array.
This is a major version bump, but the changelog at
https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v66.0.0
doesn't indicate any breaking changes that should impact us.
However, improved rules do require a small number of changes here:
- The `prefer-array-some` rule no longer reports a false positive after
https://github.com/sindresorhus/eslint-plugin-unicorn/issues/3198 got
fixed, so the ignore line that was added in commit 68a5ec1 is removed.
- The `prefer-ternary` rule triggers on more cases now, in particular
`let` declarations with `if` reassignments, so a number of changes are
made to make it pass again.
- The `prefer-at` rule triggers on more cases now, in particular
`substring` calls that just extract a single character, so one change
is made to make it pass again.
We currently download Chrome/Firefox immediately on `npm install`
invocations because Puppeteer's postinstall script does that by default.
However, this is wasteful if the user/workflow doesn't actually need to
run Puppeteer or its browsers, for example in GitHub Actions workflows
that do linting, static analysis or other tasks like updating locales or
publishing artifacts.
This commit therefore makes sure no browser binaries get pulled in by
default anymore, and defers doing that until it's actually necessary,
which is when we want to start the browsers in the `startBrowsers`
function of `test.mjs`.
Locally this brings the `npm install` runtime down from 8.998 to 1.800
seconds, and as a bonus it results in better log output too because it
now shows which browser versions were used in the run (whereas
previously with `npm install` this information was not sent to stdout).
We currently use the pinned version of Chrome as hardcoded in the
Puppeteer release, which is based on the version of Chrome that was
deemed stable at the time of the Puppeteer release.
However, this is not ideal because it means that Chrome updates are
strongly tied to Puppeteer releases, so if Puppeteer releases are slow
we could be missing out on e.g. (security) patches being applied on the
stable channel. It's also not consistent with Firefox where we don't
use a hardcoded pinned version either.
This commit therefore configures Puppeteer to use (resolve) the most
recent stable version of Chrome at the time of the installation so that
determining the browser version to use is fully decoupled from the
Puppeteer release we're running.
The effect of this change can be seen in the output of running
`npx puppeteer browsers list`:
Before:
`chrome@149.0.7827.22 (linux) <path>`
After (note the slightly newer version):
`chrome@149.0.7827.115 (linux)` <path>`
Nowadays Chrome has a built-in (new) headless mode in the regular
binary, but before that time there was an old headless mode that was
essentially a separate binary [1]. We don't use the latter, but it turns
out that Puppeteer downloads it automatically if it's not explicitly
skipped, which is wasteful because it costs extra time and resources for
each `npm install` invocation.
This commit therefore skips downloading Chrome headless shell explictly,
which results in the local runtime of `npm install` going from 10.125
seconds to 8.998 seconds (which can't hurt in e.g. GitHub Actions).
[1] https://developer.chrome.com/blog/chrome-headless-shell.
The "Merge PDF" integration-tests will (indirectly) invoke `PDFViewerApplication.open` as part of loading the new PDF document, which will end up creating a new `PDFWorker` instance.
Currently worker coverage is only collected at the end of each integration-test, which means that in these cases we miss the coverage data from any "previous" workers.
Currently when opening a PDF document the following code is used, where `checkFirstPage`/`checkLastPage` helps detect XRef corruption; note 86a18bd5fe/src/core/worker.js (L167-L176)
However when merging a PDF into an existing document the parsing is only "partial"; note 86a18bd5fe/src/core/worker.js (L632-L634)
It seems a little strange to not support corrupt PDFs in a consistent manner in the code-base, hence this patch adds a new `BasePdfManager` helper that handles all the relevant parsing/checking and re-uses that when merging PDFs.
We use the generic `page.mouse.move(x, y, { steps }` API, but that purely
performs the mouse move steps without having knowledge about if/how the
application handles any events caused by it, so it doesn't wait for the
sidebar to render before moving on. This causes intermittent failures if
the sidebar didn't get enough time to render before the next mouse move
is initiated (which can happen in slower environments).
This commit fixes the issue by doing the mouse move steps ourselves and
by waiting for a browser trip between each of them to make sure that the
sidebar got a chance to render.
Fixes#21447.
Relates to #21044 / #21045 / 24e5377.
