This is a major version bump, but the changelog at
https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v54.0.0
doesn't indicate any breaking changes that should impact us.

…fied-legacy builds (issue 18290)

[Editor] Remove the various listeners when destroying the editor manager

This has two advantages, as far as I'm concerned:
 - The tests don't need to manually invoke multiple functions to properly clean-up, which reduces the risk of missing something.
 - By collecting all the relevant clean-up in one method, rather than spreading it out, we get a much better overview of exactly what is being reset.

Update dependencies to the most recent versions and upgrade `eslint-plugin-unicorn` to version 54.0.0

…t-improve-regex

Update the regular expression in `tweakWebpackOutput` to support minified-legacy builds (issue 18290)

This commit introduces a test to ensure that:
- When zooming below the maxCanvasPixels limit, the canvas is rendered
  with the correct size (the two sides are multiplied by the zoom factor).
- When zooming above the maxCanvasPixels limit, the canvas size is capped.

Ensure that we never round the canvas dimensions above `maxCanvasPixels`
by rounding them to the preceeding multiple of the display ratio rather
than the succeeding one.

Add a new helper, in the viewer, to close everything during testing

…xels

Respect `maxCanvasPixels` when computing canvas dimensions

…viewer has been closed

By closing `PDFFindBar` we also disconnect the `ResizeObserver`, since we've seen at least one case where that's running during shutdown: http://54.193.163.58:8877/91c40554d1b07c0/output.txt

…eam` (issue 18298)

Following in the footsteps of PR 17340.

[Editor] Don't create an observer for the stamp annotation after the viewer has been closed

…a stamp with an alt text (bug 1903589)

Don't throw if there's not enough data to get the header in `FlateStream` (issue 18298)

[Editor] Correctly set the accessibility data when copying & pasting a stamp with an alt text (bug 1903589)

…bar-close

Close `PDFFindBar` when closing the viewer during testing

Always use DW if it's a number for the font default width (bug 1903731)

Allow apps with supportsIntegratedFind to better monitor the find state.

A recognized use case is the Firefox findbar, its "not found" sound must
consider `entireWord` and only make noise when it is off.

See related implementation in
https://hg.mozilla.org/mozilla-central/rev/16b902cbcf26

This change can help if we have to move the implementation from cpp to jsm.

Use the new formatted issue templates

Expose entireWord in updateFindControlState

Even with PR 18280 fixed, we still *occasionally* see l10n-related errors when closing the integration-tests on the bots.

Update dependencies and translations to the most recent versions

Try to shutdown Fluent "more" when closing the viewer during testing

This commit fixes the following log line that currently shows up for
every type of tests that involve a browser:

`System addon update list error SyntaxError: XMLHttpRequest.open:
'http://%(server)s/dummy-system-addons.xml' is not a valid URL.`

If Firefox is in testing mode, the system addons update URL is
configured to a dummy URL so that it can't actually update (see for
example the same value in Marionette at
https://searchfox.org/mozilla-central/source/testing/marionette/client/marionette_driver/geckoinstance.py#109),
but this doesn't stop Firefox from trying to update, and when it does
it logs this line because the URL is obviously invalid.

Hence this patch which disables system addon updates altogether so
Firefox doesn't attempt to use the dummy URL anymore. The browser
updates are all managed by Puppeteer, and regular updates have already
been disabled too (see
https://github.com/puppeteer/puppeteer/blob/6937a76f0a442eca0c6381587b47298793798913/packages/browsers/src/browser-data/firefox.ts#L302-L303).

This integration test is currently the only one that spawns a separate
browser instance. However, while it closes the browser once it's done,
it doesn't close the page (and therefore doesn't call the `testingClose`
method) like the other integration tests do.

This commit fixes this difference by closing the page before closing the
browser, thereby ensuring all regular cleanup logic gets called and we
avoid (intermittent) shutdown tracebacks in the logs. This allows
upcoming integration tests that spawn a separate browser instance to
reuse this pattern to cleanly end the test.

Given that we integrate the `closeSinglePage` code from mozilla#17962 for this
patch, @calixteman is credited as the co-author.

Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>

…addons-xpi

Disable system addon updates for Firefox in testing mode

…separate-browser-cleanup

Close the page in the text layer caret selection integration test

…test

This integration test contains three issues:

- The `page.bringToFront()` call is not awaited, even though it returns
  a promise (see https://pptr.dev/api/puppeteer.page.bringtofront). Note
  that in other tests we do this correctly already.
- The `page.waitForSelector()` call at the end is unnecessary because
  that exact condition is already checked at the end of the
  `waitForImage` function we call just before this line; see
  https://github.com/mozilla/pdf.js/blob/master/test/integration/stamp_editor_spec.mjs#L74.
- The pages should be closed in reversed order; please refer to the
  description in mozilla#18318 for more details.

Fixes mozilla#18318.

…tabs

Fix the "copy/paste from a tab to an other" stamp editor integration test

Currently errors in `afterAll` are logged, but don't fail the tests.
This could cause new errors during test teardown to go by unnoticed.

Moreover, the integration test use a different reporting mechanism which
also handled errors differently (this is extra reason to do mozilla#12730).

This patch fixes the issues by consistently handling errors in
`suiteStarted` and `suiteDone` in both reporting mechanisms.

Fixes mozilla#18319.

This makes sure that security researchers can find the required
information for reporting security vulnerabilities in a standardized
manner across GitHub repositories. Please refer to
https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
for more information.

…ignored-errors

Don't ignore errors in the Jasmine suite start/end stages

Include a security policy for PDF.js

This commit fixes two issues that have been found after commit 2beae7a
landed, namely:

- The security checkbox image is not rendering at
  https://github.com/mozilla/pdf.js/security/policy because the
  `SECURITY.md` file is apparently served differently there (because it
  does work as expected at
  https://github.com/mozilla/pdf.js/blob/master/.github/SECURITY.md),
  which causes the relative link not to work. We switch to an absolute
  link to fix the issue.
- If a security policy is defined it turns out that GitHub automatically
  adds a row to the "New issue" page; see
  https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
  where it states "When someone creates an issue in your repository, they
  will see a link to your project's security policy". Since we now have
  two rows at https://github.com/mozilla/pdf.js/issues/new/choose about
  the security policy, we remove our own version in favor of the
  standard GitHub-provided one.

Improve the security policy

…ve coefficients

It's a follow-up of mozilla#18253.

…unction

Debugging mozilla#17931, by printing all parts of the event lifecycle including
timestamps, uncovered that some events for which a timeout was logged
actually did get triggered correctly in the browser. Going over the code
and discovering https://stackoverflow.com/questions/47107465/puppeteer-how-to-listen-to-object-events#comment117661238_65534026
showed what went wrong: if the event we wait for is triggered then
`Promise.race` resolves, but that doesn't automatically cancel the
timeout. The tests didn't fail on this because `Promise.race` resolved
correctly, but slightly later once the timeout was reached we would see
spurious log lines about timeouts for the already-triggered events.

This commit fixes the issue by canceling the timeout if the event we're
waiting for has triggered.

Fix the computation of unitsPerEm when the fontMatrix has some negative coefficients

…timeouts

Fix the timeout logic in the `waitForEvent` integration test helper function

…r function

This code contains the same bug that the previous commit fixed in
`waitForEvent`, namely that we don't clear the timeout if the event
is triggered. By using the now fixed `waitForEvent` function we not
only deduplicate this code but we also fix this issue so that no
incorrect timeout logs show up anymore.

…pastefromclipboard

Use `waitForEvent` in the `pasteFromClipboard` integration test helper function

Browsers have an accessibility option that allows user to enforce
a minimum font size for all text rendered in the page, regardless
of what the font-size CSS property says. For example, it can be
found in Firefox under `font.minimum-size.x-western`.

When rendering the <span>s in the text layer, this causes the
text layer to not be aligned anymore with the underlying canvas.
While normally accessibility features should not be worked around,
in this case it is *not* improving accessibility:
- the text is transparent, so making it bigger doesn't make it more
  readable
- the selection UX for users with that accessibility option enabled
  is worse than for other users (it's basically unusable).

While there is tecnically no way to ignore that minimum font size,
this commit does it by multiplying all the `font-size`s in the text
layer by minFontSize, and then scaling all the `<span>`s down by
1/minFontSize.

…in-font-size

Override the minimum font size when rendering the text layer

…troy` (PR 18313 follow-up)

With `@fluent/dom 0.10.0` just published this work-around is no longer necessary.

…equestAnimationFrame

Remove the `requestAnimationFrame` work-around in `L10n.prototype.destroy` (PR 18313 follow-up)

…l (bug 1904585)

Add the possibility to dispatch some pdf.js events at the chrome level (bug 1904585)

The integration tests are currently not consistent in how they do
copy/pasting: some tests use the `kbCopy`/`kbPaste` functions with
waiting for the event inline, some have their own helper function to
combine those actions and some even call `kbCopy`/`kbPaste` without
waiting for the event at all (which can cause intermittent failures).

This commit fixes the issues by providing a set of four helper functions
that all tests use and that abstract e.g. waiting for the event away
from the caller. This makes the invididual tests simpler and consistent,
reduces code duplication and fixes possible intermittent failures
due to not waiting for events to trigger.

…lper function

Debugging mozilla#17931 uncovered a race condition in the way we use the
`waitForEvent` function. Currently the following happens:

1. We call `waitForEvent`, which starts execution of the function body
   and immediately returns a promise.
2. We do the action that triggers the event.
3. We await the promise, which resolves if the event is triggered or
   the timeout is reached.

The problem is in step 1: function body execution has started, but not
necessarily completed. Given that we don't await the promise, we
immediately trigger step 2 and it's not unlikely that the event we
trigger arrives before the event listener is actually registered in the
function body of `waitForEvent` (which is slower because it needs to be
evaluated in the page context and there is some other logic before the
actual `addEventListener` call).

This commit fixes the issue by passing the action to `waitForEvent` as
a callback so `waitForEvent` itself can call it once it's safe to do so.
This should make sure that we always register the event listener before
triggering the event, and because we shouldn't miss events anymore we
can also remove the retry logic for pasting.

…copy-pasting

Refactor the copy/paste logic in the integration tests and fix a race condition involving the `waitForEvent` integration test helper function

…193 follow-up)

While the event listener is removed during testing, the `requestAnimationFrame` isn't cancelled and that occasionally shows up when the integration-tests are run on the bots.

…lAnimationFrame

Cancel the `requestAnimationFrame` in the `watchScroll` helper (PR 18193 follow-up)

Errors related to this `requestAnimationFrame` show up intermittently when running the integration-tests on the bots, however I've been unable to reproduce it locally.
Hence I cannot guarantee that it's enough to fix the timing issues, however this should be generally safe since the `requestAnimationFrame` invokes the `_next`-method and the first thing that one does is check that rendering hasn't been cancelled.

They're potentially due to some concurrent access to the system clipboard.
So this patch makes them sequential.

…k-cancel-cancelAnimationFrame

Cancel the `requestAnimationFrame` in the API when cancelling rendering

Add a port option to gulp server

Fix intermittent failures with freetext and stamp tests

Ignore test issue17779.pdf in talos because it times out

… some fields

Take into account PageOpen and PageClose actions which are present in some fields

Add a comment about `test/webserver.mjs` being development-only code

…yer` functions (PR 18104 follow-up)

This commit migrates this functionality away from the bots. Note that
the NPM token must be configured as a repository secret before this
workflow can execute.

The following resources are relevant for this patch:

- Publishing packages to the NPM registry:
  https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages#publishing-packages-to-the-npm-registry
- Creating secrets for a repository:
  https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository

This commit removes the following warnings from the `npm publish` output:

```
npm warn publish npm auto-corrected some errors in your package.json when publishing.  Please run "npm pkg fix" to address these errors.
npm warn publish errors corrected:
npm warn publish Removed invalid "scripts"
npm warn publish "repository.url" was normalized to "git+https://github.com/mozilla/pdfjs-dist.git"
```

For the "scripts" section it turns out that if the package doesn't have
any scripts it's expected to explicitly set it to an empty object; refer
to npm/cli#6918 and
denoland/dnt#414.

…lease

Introduce a GitHub Actions workflow for publishing a release and fix `npm publish` warnings about the `package.json` format

This PR switches from `npm install` to `npm ci` on CI. This enables some additional checks to ensure repo integrity when using CI/CD.

Read more: https://docs.npmjs.com/cli/v10/commands/npm-ci

Use `npm ci`, not `npm install`, on CI

This PR adds [Provenance statements](https://docs.npmjs.com/generating-provenance-statements) on `npm publish`, increasing supply-chain security.

It should help to have such a garbage in the logs:
```
console.warn: TopSitesFeed: Failed to fetch data from Contile server: NetworkError when attempting to fetch resource.
JavaScript error: , line 0: TypeError: NetworkError when attempting to fetch resource.
```

Disable new tab page stuff in Firefox when running tests

Generate provenance statements on npm publish

For provenance, enabled in PR mozilla#18352, to work the repository URL in
`package.json` is required to match the repository URL of the GitHub
Actions invocation. This should fix the following error we encountered
publishing a new release today:

```
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/pdfjs-dist - Error verifying sigstore provenance bundle: Failed to validate repository information: package.json: "repository.url" is "git+https://github.com/mozilla/pdfjs-dist.git", expected to match "https://github.com/mozilla/pdf.js" from provenance
```

Fix the repository URL in the `package.json` file for `pdfjs-dist`

Bump the stable version in `pdfjs.config`

…adpoints when saving an highlight

It fixes mozilla#18360.

[Editor] Take into account the page translation when computing the quadpoints when saving an highlight

…aining editable annotations

Right now, editable annotations are using their own canvas when they're drawn, but
it induces several issues:
 - if the annotation has to be composed with the page then the canvas must be correctly
   composed with its parent. That means we should move the canvas under canvasWrapper
   and we should extract composing info from the drawing instructions...
   Currently it's the case with highlight annotations.
 - we use some extra memory for those canvas even if the user will never edit them, which
   the case for example when opening a pdf in Fenix.

So with this patch, all the editable annotations are drawn on the canvas. When the
user switches to editing mode, then the pages with some editable annotations are redrawn but
without them: they'll be replaced by their counterpart in the annotation editor layer.

…tly in mozilla-central (bug 1905864)

[api-minor][Editor] When switching to editing mode, redraw pages containing editable annotations (bug 1883884)

Co-authored-by: Jonas Jenwald <jonas.jenwald@gmail.com>

Bump library version to 4.5

…ion editor mode

[Editor] Make sure everything is cleaned up when we switch to annotation editor mode