While this shouldn't affect performance negatively, it does however (ever so slightly) increase the bundle size of the Firefox PDF Viewer.
If that's not desirable, since it's only needed in order to improve Node.js compatibility, we could also just WONTFIX the issue.
The Type3 glyphs are parsed in series, which was implemented by chaining the `getOperatorList` promises together one after another.
Thanks to modern JavaScript this can be simplified a little bit, since we can just `await` within the loop instead.
`parseQueryString`, i.e. `URLSearchParams`, has already percent-decoded the
parameter, hence re-encoding it with `encodeURIComponent` and only restoring
the slashes leaves e.g. "?", "&" and "%" escaped. This breaks relative URLs
with a query string, e.g. `?file=%2Fget.jsp%3Fid%3D1%26x%3D2`, and relative
URLs with a percent-encoded path.
The value is now used as-is, except for a "#" in a relative URL which is
still escaped: since the viewer takes its own hash parameters from the
*viewer* URL, a "#" in the `file` parameter is assumed to be part of the
filename (see #19990).
It fixes#20137.
The remaining rules from the plugin's "Best Practices" category that the
recommended config leaves off, plus the two it only warns about, all of
which the code already complies with.
`regexp/prefer-regexp-test` is left off, since `unicorn/prefer-regexp-test`
already covers it.
`\d+\.?\d*` can split a run of digits in as many ways as it is long, so
it would backtrack polynomially if anything following it could reject.
The optional exponent can't, hence no bug today, but `\d+(?:\.\d*)?`
accepts the same numbers unambiguously.
It flags the regexes whose search is quadratic in the input length, like
the autolinker and XFA-path ones fixed recently.
The three existing offenders: `\s*` matched the CSS indentation but also
the line terminators that make `^` match with the `m` flag (the
preprocessed CSS is unchanged), `(\d+)` made every digit of a number a
candidate start position, and `/T.*$/` could fail on the `$` and
backtrack since `.` doesn't match a line terminator.
When a viewer page was copied, each copy got its own annotationStorage
entry, but newAnnotationsByPage was keyed only by source page. As a
result, every output copy received all entries and reused their memoized
references.
Tag each entry with its rank among output copies of the same source page.
The display and worker compute this rank independently; inserted documents
preserve the order of copies. Keep unextracted entries at rank -1 so shared
stamp bitmaps remain available without being written. Without ranks, new
annotations are applied only to the first copy.
Follow-up to PR #21690: these tests check that pressing Home/End
correctly updates the last focused menu-item index, so that a following
ArrowUp/ArrowDown press doesn't move focus to an unexpected menu-item.
When an AcroForm has no Fields entry, #fixFields rebuilds it by walking
each widget's Parent chain up to its root field. A chain looping back on
itself made that walk spin forever and hung the worker.
This fixes a bug when using the <kbd>Home</kbd> and <kbd>End</kbd> keyboard shortcuts to navigate through a `Menu` instance. These two buttons didn't update the `#lastIndex` field, which means that e.g. a following <kbd>ArrowDown</kbd> or <kbd>ArrowUp</kbd> press could make focus "jump" to an unexpected menu-item.
Also, the helper method reduces a little bit of code duplication in the event handlers.
Matching the name with a leading `.+` is quadratic in the length of
a component which doesn't end with a position, and every AcroForm
field name goes through this.
`toFixed(10)` switches to the exponential notation from 1e21 on, which isn't
valid PDF syntax, and removing the trailing zeros then dropped a digit of the
exponent: 1e30 was written "1e+3" and 1e100 "1e+1". Such a number, necessarily
an integer, is now written with all its digits.
The trailing zeros are removed with a backward scan, since `toFixed(10)` always
produces exactly 10 decimals. Below the 1e21 limit its output is at most 33
characters long, so the previous `$`-anchored regex wasn't a performance issue.
The local part and the domain labels were unbounded, making the
search quadratic in the length of a run of characters preceding
an "@": scanning the text of a single page could take seconds.
Compared to regular Objects there's a number of advantages to using Maps:
- They support proper iteration.
- They have a simple way to check for the existence of data.
- They have a simple/efficient way to check the number of elements.
If this functionality was added today, I cannot imagine that we'd choose an Object for this data.
In the Firefox PDF Viewer sending Maps to the scripting-implementation should be fine, since it uses the browser `Cu.cloneInto` functionality; see https://searchfox.org/firefox-main/source/toolkit/components/pdfjs/content/PdfSandbox.sys.mjs
However with QuickJS, used by the GENERIC viewer, all data needs to be stringified and Maps are converted into regular Objects (see also PR 21664). Hence the `objects` property, in the scripting-implementation, is converted back into a Map using the (renamed) `createMap` helper function.
