- Shorten the `getURL` function slightly, by re-factoring the try-catch blocks.
- Change how the `decode` function looks for a decoded ".pdf" name, to skip the regular expression matching when it's not needed and to allow re-using the already defined `pdfRegex`.
This was necessary before charset compilation was implemented, however that's been supported for many years and this is just dead code now.
- PR 9340, back in 2018, stopped using the `raw` field.
- PR 10591, back in 2019, implemented proper charset compilation.
The `CFFFont.prototype.data` should contain a `Uint8Array`, however if compilation failed it was being set to a `Stream` instance which will thus fail elsewhere in the font-code.
*Please note:* This was found by code inspection, since I don't have a PDF document that's fixed by this change.
Return the data as-is from the `CFFCompiler.prototype.compile` method, rather than making a copy of it first.
The reason that it was implemented this way in PR 21053 was to avoid keeping a potentially large `ArrayBuffer` alive, see https://github.com/mozilla/pdf.js/pull/21053#discussion_r3045402988
Having traced all the call-sites in the font-code that directly or indirectly invoke that code, I've now managed to conclude that the compiled CFF-data is never stored on the `Font` instance and using the data as-is thus shouldn't increase permanent memory usage.
The find controller tests consistently show up in the list of slowest
tests reported by Jasmine. Profiling shows that most of the time is
spent waiting for the find results to arrive, even though the find
command itself is quite fast.
It turns out that the slowdown occurs between receiving the `find` event
and actually triggering the search. The find controller has a hardcoded
delay of 250 milliseconds built in, which was introduced for viewer
performance many years ago because otherwise every keystroke would
trigger a search even though the user's query was not complete yet.
For the unit tests we don't need this delay because, contrary to the
viewer use case, we don't have to account for user interaction and
instead dispatch complete `find` events on the event bus ourselves.
However, since the unit tests were introduced well over a year after
the delay was introduced, due to an oversight it was never made
configurable so we could skip it for the unit tests.
This commit fixes the issue, which locally results in the runtime of
`npx gulp unittest --noChrome` dropping from 39.991 seconds before this
patch to 29.116 seconds afterwards, which is a 27% speedup.
In a previous commit the time-based checks, which were based on
statistics provided by the `pdfBug: true` flag, got replaced by
test-only property checks that don't use said statistics anymore.
Fixes b01eeaf8.
This commit fixes a number of missing cleanup steps in the unit tests
that kept state alive for longer than necessary:
- the loading tasks were not all being destroyed;
- the find controllers were not being reset;
- the state set in `beforeAll`/`beforeEach` was not all being nulled in
the correspoding `afterAll`/`afterEach` blocks.
Combined this resulted in a steady increase in memory usage of the test
process as the tests ran, climbing up to ~1.5 GB. After this patch the
memory usage remains stable at ~800 MB.
Given that all of the relevant API methods are asynchronous it's possible, although quite unlikely, that the existing "is the document active" check won't catch all situations where the document was closed in the middle of searching.
This handles *all* errors correctly, if e.g. the document is closed in the middle of searching.
Also, replacing the "promise chains" with more `await` helps simplify the code a little bit.
disable_search == true, will avoid useless search especially because we already provide the path to the info file.
disable_telem == true, disable sending telemetry to codecov.
Originally we introduced a separate `coverage.yml` workflow to
test-drive coverage collection without immediately introducing it inline
in the `ci.yml` workflow. However, now that coverage collection works
nicely and is performant enough we can simplify the workflow definitions
by removing `coverage.yml` entirely in favor of simply inlining coverage
collection into the existing `unittestcli` run in `ci.yml`. Doing so
also avoids having to a full extra `unittestcli` run just to collect
coverage information.
Moreover, this commit aligns coverage collection flags with the ones in
the other workflows to be more explicit and consistent.
The thumbnails are only available if the first page is ready, and not
awaiting that causes the drag-and-drop action to be performed using
incorrect thumbnail viewer state (see the analysis in #21184 for more
details).
Fixes#21184.
Supersedes #20902.
Unblocks #21173.
This avoids having to "duplicate" dummy `readBlock` methods in a couple of image-stream classes.
Also, move a few `DecodeStream` field definitions to (ever so slightly) shorten the code.
