Note that we no longer create an empty file if the download fails because
we don't want to leave traces of incorrect file contents on disk. This
has never been particularly useful because it'd require a manual user
action to remove the empty file to be able to retry in case of e.g. a
timed out connection, but especially in the context of GitHub Actions
where we cache the PDFs directory we don't want to cache invalid files
to make sure that a next run will automatically retry to fetch any
previously missed PDF files and update the cache.
*Note:* This is similar to PR 19525, which did the same thing for the OpenJPEG decoder.
The advantages of doing this are:
- The same JBig2 decoder is used regardless of WASM being supported or not, which means consistent rendering.
- The old `Jbig2Image` implementation has various bugs and missing features.
- Less code that needs to be maintained in the PDF.js project, since both the CCITT and the JBig2 decoder is replaced.
The disadvantage of doing this is:
- Slightly larger bundle size, however the effect is limited since a fair amount of PDF.js code can be removed. For the `gulp mozcentral` target the size increase is approximately 54 kilo-bytes (which is small compared to the 452 kilo-bytes for the JS version of the OpenJPEG decoder).
Rather than relying on the time it takes to parse/render the pages, which leads to intermittent failures, add a test-only property and use it to check if the "CopyLocalImage" code-path was exercised.
Instrument JS files on-the-fly via babel-plugin-istanbul when --coverage
or --coverage-per-test is passed, producing an aggregate lcov/HTML report
at the end of the run. A persistent PDFWorker accumulates worker-thread
coverage alongside the main-thread coverage, collected via a new
GetWorkerCoverage message handler.
With --coverage-per-test, an inverted index
(build/coverage/per-test-index.json) is also built as tests run, mapping
each hit source line and function name to the numeric IDs of the tests
that exercised it, keeping the output compact. The new
`gulp test_search --code=file::line_or_function` tool queries the index,
and passing --code to browsertest pre-filters the test run to only those
tests.
Coverage output formats are selectable via --coverage-formats (default:
info; also accepts html, json, text, cobertura, clover).
This unit test failed consistently in Firefox both locally and on GitHub
Actions (but not in Chrome or on the bots), which suggests a timing issue.
Since all other unit tests that rely on `commonObjs` actually render the
page, most likely to make sure that `commonObjs` is fully populated at
the time of the check, this commit mirrors that approach to this test,
which indeed fixes the issue.
Replace manifest slicing with a dynamic task queue: drivers request tasks
on demand via WebSocket so parallel sessions self-balance naturally.
Start reading reference PNGs from disk as soon as a task is dispatched
(prefetchRefPngs) to overlap I/O with rendering. Release snapshot
buffers and task entries immediately after comparison, and copy WS
frame slices via Buffer.from() so the original frame buffer can be
GC'd.
Bump --max-old-space-size to 8192 MB as a workaround for a
Puppeteer/BiDi memory leak where data: URL strings accumulate in
BrowsingContext.#requests indefinitely:
https://github.com/puppeteer/puppeteer/issues/14876
- Replace base64/JSON POST image submission with binary WebSocket frames,
avoiding base64 overhead and per-request HTTP costs; quit is also sent
over the same WS channel to guarantee ordering
- Prefetch the next task's PDF in the worker while the current task is
still rendering
- Use `getImageData` instead of `toBlob` for partial-test baseline
comparison (synchronous, no encoding); only encode to PNG in master mode
- Disable bounce tracking protection in Firefox to prevent EBUSY errors
from Puppeteer's profile cleanup on Windows
One browser per job is opened and will run a subset of the tests.
The goal is to make the tests significantly faster on machines with a good number of cpus.
After the previous patches the `string32` helper function is now only used in the `FontLoader.prototype._prepareFontLoadEvent` method, which is stubbed out in the Firefox PDF Viewer, hence move it there instead to avoid bundling dead code.
1. Record `fill` dependencies even if we early return due to `isPatternFill``
2. Isolate the `drawPattern` inner `executeOperationList` in a
`CanvasNestedDependencyTracker` so that it does not consume pending
dependencies from the outer list.
Currently the `CFFCompiler.prototype.compile` implementation seem a bit inefficient, since the data is stored in a plain Array that needs to grow (a lot) during compilation. Additionally, adding a lot of entries isn't very efficient either and requires special handling of the "too many elements" case.
Some of the "helper" methods that use TypedArrays internally currently need to convert their return data to plain Arrays, via the `compileTypedArray` method, which adds even more intermediate allocations.
Note also that the `OpenTypeFileBuilder` has a special-case for writing plain Array data, which is only needed because of how the CFF compilation is implemented.
To improve this situation the `CFFCompiler.prototype.compile` method is re-factored to store its data in a TypedArray, whose initial size is estimated from the "raw" file size.
This removes the need for most intermediate allocations, and it also handles adding of "many elements" more efficiently.
One drawback of the current implementation is that the GPU device can be
unavailable at the time of the first pattern fill, which causes the
GPU-accelerated canvas to be move on the main thread because of putImageData.
Most of the shading patterns stuff will be moved to the GPU and in order
to avoid creating some useless data we've to know if the GPU is available or not.
So in this patch we create the GPU device during the worker initialization
and pass a flag to the evaluator to know if the GPU is available or not.
Firefox 148 shipped with a single killswitch to disable current and
future AI/ML functionality. This can be controlled in the GUI via
`Settings -> AI Controls -> Block AI enhancements`, but can also be
controlled programmatically via the `browser.ai.control.default`
preference.
This commit uses this single preference to replace the multiple
preferences we had to use for this purpose before.
Extends 844681a.
In PR #20887 the issue got fixed partly, but two issues remained that
unintendedly left room for intermittent failres:
- in the "Ctrl+ArrowLeft/Right" loop the `waitForBrowserTrip` call was
placed _before_ the actual keypresses, which means that for the final
iteration of the loop the last key presses were not properly awaited;
- in the "ArrowLeft/ArrowRight" loop the `waitForBrowserTrip` call was
absent, which means that we didn't wait for key presses at all.
This commit fixes the issues by consistently waiting to a browser trip
_after_ each key press to make sure the sidebar got a chance to render.
There is generally a small amount of time between the find call being
reported as finished and the find count results text being updated with
the correct number in the DOM, so the integration tests will fail if we
check the find results count text too soon.
This commit fixes the issue by using the `waitForTextToBe` helper
function to wait until the find count results text is what we expect it
to be. Note that we already use this helper function for this exact
purpose in other integration tests (related to reorganizing pages), and
it's also a little bit shorter/easier to read which cannot hurt.
This improves readability by removing "magic" numbers, and matches what
we already have for e.g. annotation and shading types.
Note that function type 1 does not exist in the specification, but that
also applies to everything higher than 4, so we can also remove the
specific handling of function type 1 and instead just let it fall
through to throwing an exception for unknown function types, in which we
now also log the provided function type to aid debugging.
This test-case is an especially "bad" one performance wise given its PostScript function use, when falling back to the (now removed) `PostScriptEvaluator` code.
These classes, and various related code, became unused after PR 21023 with only unit-tests actually running that code now.
Also removes the `isEvalSupported` API option, since the `PostScriptCompiler` was the only remaining code where `eval` was used.
