Group and scope the findbar rules using CSS nesting

…alt text dialog

There's a fair number of event listeners in the editor-code that we're currently removing "manually", by keeping references to their event handler functions.
This was necessary since we have a "global" `AbortController` that applies to all event listeners used in the editor-code, however it's now possible to combine multiple `AbortSignal`s; please see https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static

Since this functionality is [fairly new](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static#browser_compatibility) the viewer will check that `AbortSignal.any()` is available before enabling the editing-functionality.
(It should hopefully be fairly straightforward, famous last words, for users to implement a polyfill to allow editing in older browsers.)

Finally, this patch also adds checks and test-only asserts to ensure that we don't add duplicate event listeners in various editor-code.

[Editor] Change the background color of the image preview in the new alt text dialog

[Editor] Remove event listeners with `AbortSignal.any()`

…586 follow-up)

Without this patch the viewer may break on load, since the check added in PR 18586 only applies to the toolbar.

…nal-any

Check that `AbortSignal.any()` is supported in `PDFViewer` too (PR 18586 follow-up)

…image data to the model"

Revert "[Editor] Pass a buffer instead of a typed array when passing image data to the model"

…l.any()`

This, ever so slightly, shortens the code for a couple of repeatedly accessed class fields.

Because of an old oversight (by me) we don't stop sidebar resizing when the browser window loses focus, which seems generally wrong and can also lead to duplicate mouse-related event listeners being registered.

This was enabled by default in Firefox 126, see [bug 1867513](https://bugzilla.mozilla.org/show_bug.cgi?id=1867513), so hopefully we should be able to remove the option/preference now.

[Editor] Add a first test to test the new alt text flow

[Firefox] Remove the "loadaiengineprogress" listener with `AbortSignal.any()`

Remove the sidebar resizing event listeners with an `AbortController`

[Editor] Add the telemetry for the new alt text (bug 1912500)

…ng CSS nesting

The secondary toolbar CSS rules predate the general availability of CSS
nesting, which makes them more difficult to understand and change
safely. The primary issues are that the rules are spread over the
`viewer.css` file, they share blocks with other elements and the scope
of the rules is sometimes bigger than necessary.

This refactoring groups all CSS rules for the secondary toolbar button
container/icons together, scoped to the top-level `#secondaryToolbar`
element, for improved overview and isolation. Note that this patch only
intends to move the existing rules around and not change any behavior.
Moreover, this patch does not move the rules for the secondary toolbar
itself and the secondary toolbar buttons; those will be part of a
follow-up patch and will be easier once this is in place first.

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

…rt-1

Group and scope the secondary toolbar button container/icon rules using CSS nesting

Secondary toolbar buttons are toolbar buttons with some extra rules,
mainly to make them wider and have visible labels. However, this
similarity is currently not clearly reflected in the implementation
because the secondary toolbar buttons use a different CSS class,
`secondaryToolbarButton`, compared to the other toolbar buttons that
use the `toolbarButton` CSS class. This also causes some duplication
in the rules and requires extra care to keep the common bits for the
`secondaryToolbarButton` class in sync with the `toolbarButton` class.

Fortunately, now that we have a dedicated CSS scope for the secondary
toolbar, we can simplify this by giving all secondary toolbar buttons
the `toolbarButton` class and explicitly listing the required overrides
in the `#secondaryToolbar` scope instead. Doing so removes most of the
special-casing for secondary toolbar buttons while explicitly listing
the differences in a single place for a better overview. It also lays
the foundation for making all toolbar buttons respect the
`browser.uidensity` Firefox preference later by reducing differences.

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

…rt-2

Remove the `secondaryToolbarButton` CSS class

The secondary toolbar CSS rules predate the general availability of CSS
nesting, which makes them more difficult to understand and change
safely. The primary issues are that the rules are spread over the
`viewer.css` file, they share blocks with other elements and the scope
of the rules is sometimes bigger than necessary.

This refactoring groups all remaining secondary toolbar rules together,
scoped to the top-level `#secondaryToolbar` element, for improved
overview and isolation. Note that this patch only intends to move the
existing rules around and not change any behavior.

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

We have a number of base-classes that are only intended to be extended, but never to be used directly. To help enforce this during development these base-class constructors will check for direct usage, however that code is obviously not needed in the actual builds.

*Note:* This patch reduces the size of the `gulp mozcentral` output by `~2.7` kilo-bytes, which isn't a lot but still cannot hurt.

…rt-3

Group and scope the secondary toolbar rules using CSS nesting

…check

Limit base-class initialization checks to development and TESTING modes

Now that we have dedicated CSS scopes for the findbar and the secondary
toolbar we have ended up with two CSS blocks with identical selectors,
so now we can combine them for simplicity and to remove some rules in
the first block that were always overridden by the second block.

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

Using the `:is(a)` selector we can move the previously separate rules
into the main `.toolbarButton` override rules.

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

This commit fixes a regression from #18596 where the "Add image" button
styles broke because it's a labeled toolbar button but the labeled
toolbar button CSS rules were only scoped to the secondary toolbar.
However, nowadays labeled toolbar buttons are also used in e.g. the
editor parameters toolbar, and this highlighted that we didn't clearly
encode the concept of labeled toolbar buttons in the CSS so far.

This patch extracts the CSS rules for labeled toolbar buttons that were
previously limited to the secondary toolbar into a dedicated generic
class that can be applied on top of any unlabeled toolbar button to
convert it to a labeled toolbar button, regardless of its position in
the DOM. This also makes the distinction clearer in the HTML, and the
new CSS scope for the toolbar buttons lays the foundation for combining
the other toolbar buttons rules in there later on.

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

…-pref

Remove the `enableHighlightEditor` preference

This patch allows embedders of PDF.js to provide custom match
logic for seaching in PDFs. This is done by subclassing the
PDFFindController class and overriding the `match` method.

`match` is called once per PDF page, receives as parameters the
search query, the page contents, and the page index, and returns
an array of { index, length } objects representing the search
results.

…class

[api-minor] Allow specifying custom match logic in PDFFindController

Bump library version to `4.6`

Improve the viewer CSS after nesting the findbar and secondary toolbar rules

This shortens the code ever so slightly, which cannot hurt.

…ssue 18196)

The problem seems to be caused by the browser trying to "restore" editing input-elements, in the various toolbars, to their previous values when the tab is re-opened.

Hence the simplest solution appears to be to move the event handling into the editor-code, which is also less code overall, since the listener thus won't be registered early enough for the problem to appear.

Handle the "switchannotationeditorparams" event in the editor-code (issue 18196)

Hopefully this might lead to *more* users actually testing the latest version before reporting a bug.

…iption

Link to official releases and the demo viewer in the bug report template

Fix the telemetry for the new alt-text flow

The way that the debugging hash-parameter parsing is implemented leads to a lot of boilerplate code in this method, since *most* of the cases are very similar.[1]
With just a few exceptions most of the options can be handled automatically, by defining an appropriate checker for each option.

---

[1] With the recent introduction of TESTING-only options the size of this method increased a fair bit.

Enable disabled integration tests for Firefox

Shorten the `PDFViewerApplication._parseHashParams` method

This patch is generated automatically using `npm audit fix` and fixes
CVE-2024-39338 (see GHSA-8hc4-vh64-cxmj),
bringing the vulnerability count back to zero.

We introduced quite a few new strings recently, but during the last few
rounds of updates we didn't see new translations updates becoming
available. I only just now recalled the announcement that Mozilla is
moving from Mercurial to Git, and indeed the Mercurial page at
https://hg.mozilla.org/l10n-central hasn't been updated since July
anymore and that's were we used to pull our translations from.

This commit fixes the issue by changing the URLs to the Mozilla Git
repositories hosted on GitHub instead.

Update dependencies and translations to the most recent versions

…riggered

The function evaluateOnNewDocument in Puppeteer allow us to execute some js before the pdf.js one
is loaded.
It allows us to stub some setters before there are used and then set some event handlers very soon.

Set the event handlers in the integration tests before any event is triggered

In PR #18574 setting `window.uiManager` was moved into the `src` folder
to avoid intermittent integration test failures because at the time we
lacked a way to register event listeners early (before PDF.js loads).
However, in PR #18617 this functionality got introduced, so we can now
use the new way of setting up the event bus in the tests to move this
back to the `test` folder again and to reduce the amount of test-only
code in the main codebase as discussed in PR #18574.

Partially reverts e037c57.

…its siblings" scripting integration test

This integration test fails intermittently because we cache the initial
total value to be able to compare it to the new total value at the end
of the test to check that it's different before doing the assertions.
However, this doesn't work as expected because the second `clearInput`
call triggers an intermediate total value calculation because it clicks
on another input field and that triggers a sandbox event.

This results in the `waitForFunction` calls always resolving immediately
and since we don't use other means of waiting until the calculation is
done (using e.g. `waitForSandboxTrip`) we basically rely on the time
between the final click and the assertions to be enough for the sandbox
to do its work. If it's is not done in that time, we do the assertions
with older values and that makes the test fail.

This commit fixes the issue by simply waiting for the total value to be
what we expect it to be. This requires less code, is more consistent
with the other integration tests and removes the possibility of doing
assertions against older values.

[Editor] Move setting `window.uiManager` back to the test code

…iblings

Fix the "must check that a value is correctly updated on a field and its siblings" scripting integration test

… fonts (issue 18208)

Given that we handle non-embedded Calibri fonts as "mapped to standard font", we really ought to be able to use the same glyph mapping as for an actual standard font.
Note that this actually improves consistency in the code, given how we already handle such fonts if they happen to be of the `CIDFontType2` type; see https://github.com/mozilla/pdf.js/blob/b47c7eca83c35b8f9ea170aa3742fc70359726c2/src/core/fonts.js#L1186-L1190

Use standard glyph mapping for non-embedded and non-composite Calibri fonts (issue 18208)

- When adding page dict candidates to the lookup tree, also initiate fetching them from xref, so if they are not yet loaded at all, the XHR will be sent
 - Only at the top level - assume that if there is a /Pages tree, it is sensibly structured and the number of requests won't be too bad
- We can then await on the cached Promise without making the requests pipeline
- This has a significant performance improvement for load-on-demand (i.e. with auto-fetch turned off) when a PDF has a large number of pages in the top level /Pages collection, and those pages are spread through a file, so every candidate needs to be fetched separately
 - PDFs with many pages where each page is a big image and all the pages are at the top level are quite a common output for digitisation programmes
- I would have liked to do something like "if it's the top level collection and page count = number of kids, then just fetch that page without traversing the tree" but unfortunately I agree with comments on #8088 that there is no good general solution to allow for /Pages nodes with empty /Kids arrays

…-dict-requests-in-parallel

Send fetch requests for all page dict lookups in parallel

…rties`

Given the length of the l10n-strings we can slightly reduce verbosity, and thus overall code-size, by introducing a helper method for fetching l10n-data.

While testing this I stumbled upon an issue in the `L10n`-class, where an optional chaining operator was placed incorrectly since the underlying method always return an Array; see https://github.com/projectfluent/fluent.js/blob/48e2a62ed45ff2a62a231b2e83cfd8b332d27acb/fluent-dom/src/localization.js#L38-L77

…in `PDFLayerViewer`

Currently we *manually* fetch the "pdfjs-additional-layers" string and update the DOM-element, which was needed since we want to avoid triggering a bunch of otherwise unnecessary translation when appending the entire layer-tree to the DOM.
By introducing a new helper method in the `L10n`-class we can avoid this, and instead use a "data-l10n-id" attribute on the element (as most other viewer code does nowadays).

See https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#G6.1840792

Support an odd number of digits in hexadecimal strings (issue 18645)

The fallback is very old code, and according to the MDN compatibility data `HTMLCanvasElement.toBlob()` should be available in all browsers that we support now: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob#browser_compatibility

Don't show the print dialog when printing in some integration tests

…etL10nStr

Introduce a helper method for fetching l10n-data in `PDFDocumentProperties`

Introduce a `L10n`-method to translate an element once, and use that in `PDFLayerViewer`

…ional-toBlob

Use `HTMLCanvasElement.toBlob()` unconditionally in `PDFPrintService`

This patch is generated automatically using `npm audit fix` and fixes
CVE-2024-4067 (see GHSA-952p-6rrq-rcjv),
bringing the vulnerability count back to zero.

The `PDFDocumentProperties` dialog may not display correctly formatted data, especially in the GENERIC viewer, since it's using native methods[1] that depend on the *browser* locale instead of the viewer locale as intended.
At the time when this dialog was introduced that was probably all we could easily do, but with Fluent we're able to improve things since it's got built-in support for formatting numbers and dates. Not only does this simplify the JavaScript code, but it also gives the localizer more fine-grained control of the desired output.

Please find additional information here:
 - https://projectfluent.org/fluent/guide/builtins.html
 - https://projectfluent.org/fluent/guide/functions.html

---

[1] `toLocaleString`, `toLocaleDateString`, and `toLocaleTimeString`.

The `AnnotationLayer` may not display correctly formatted data in PopupAnnotations, especially in the GENERIC viewer, since it's using native methods[1] that depend on the *browser* locale instead of the viewer locale as intended.
With Fluent we're able to improve things since it's got built-in support for formatting dates. Not only does this simplify the JavaScript code slightly, but it also gives the localizer more fine-grained control of the desired output.

Please find additional information here:
 - https://projectfluent.org/fluent/guide/builtins.html
 - https://projectfluent.org/fluent/guide/functions.html

---

[1] `toLocaleDateString`, and `toLocaleTimeString`.

Update dependencies and translations to the most recent versions

…0n-functions

Utilize Fluent to format numbers and dates in `PDFDocumentProperties`/`AnnotationLayer`

This major version contains three breaking changes that impact us:

- The `product` option has been renamed to the more suitable `browser`.
- The `page.screenshot()` API returns a `Uint8Array` instead of a
  `Buffer`, but since `pngjs` requires a `Buffer` object we need to do
  the conversion using `Buffer.from()` before passing data to `pngjs`.
- The browser configuration should be set using a configuration file
  instead of environment variables. Note that as a bonus this allows us
  to remove the `cross-env` dependency since that was only used to set
  the Puppeteer environment variable equally for all operating systems.

For more information about the changes between the old and new Puppeteer
versions refer to https://github.com/puppeteer/puppeteer/releases.

…t flow (bug 1914480)

In preparation for migrating the Chrome extension to Manifest Version 3,
this patch removes parts of the manifest that are obsolete and/or
unsupported in MV3.

Remove ftp mentions: ftp was dropped from 6 years ago, in Chrome 59.

Remove file_browser_handlers: does not work on Chrome OS according to
#14161 . MV3 replacement needs
a different manifest key and logic, which will be added later.

Remove content_security_policy: MV3 does not support unsafe-eval CSP,
and PDF.js does not require it. This may result in a mild performance
degradation in PDFs that contain PostScript.

Remove page_action logic: When this logic was originally introduced,
Chrome showed page action buttons in the address bar, which enabled
the extension to display the button on specific PDF viewer tabs only.
In Chrome 49 (2016), pageActions were dropped from the address bar and
put in an UI area that is hidden by default. The user can pin the button
to be unconditionally visible on the toolbar, which is distracting.
Because the UX is no longer serving the original needs, this patch
removes page_action from the manifest.

These work arounds are no longer relevant to the latest Chrome versions.

[Editor] Add a missing parameter in the telemetry for the new alt text flow (bug 1914480)

…ents

Currently we manually localize and update the DOM-elements of the editor-resizers, and it seems nicer to utilize Fluent for that task.
This can be achieved by updating the l10n-strings to directly target the `aria-label` and then just setting the `data-l10n-id` on the DOM-elements.

[Editor] Utilize Fluent "better" when localizing the resizer DOM-elements

…h-disclaimer" string once

This l10n-string is being re-defined once for every editor, i.e. currently four times, which seems unnecessary.
To avoid having to check if this l10n-string exists first, we can utilize rest parameters to move it into the `AnnotationEditor._l10nPromise` Map-definition instead.

[Editor] Define the "pdfjs-editor-new-alt-text-generated-alt-text-with-disclaimer" string once

The Node.js url.parse API (https://nodejs.org/api/url.html#urlparseurlstring-parsequerystring-slashesdenotehost)
is deprecated because it's prone to security issues (to the point that Node.js doesn't even publish CVEs for it anymore).

The official reccomendation is to instead use the global URL constructor, available both in Node.js and in browsers.
Node.js filesystem APIs accept URL objects as parameter, so this also avoids a few URL->filepath conversions.

…5434)