This commit mirrors the approach from e656b833 to the other workflows
that run multiple OS/browser combinations. This approach has multiple
advantages:
- it improves performance because each job is run in its own environment
so we don't have two browsers competing for resources in the same
environment anymore;
- it improves monitoring because each job is shown separately, with its
own runtime, in e.g. the pull request checks and actions overviews,
which makes it easier to spot bottlenecks that are specific to a
certain OS/browser combination and enable follow-up optimizations.
The `textLayerImagePlaceholder` canvas added in #20626 covers scanned
pages and was not recognized as a valid pointerdown target by
`#textLayerPointerDown`, so free highlights couldn't start.
Remove the "Float32Array" mention in the comment, given that the
implementation usesa Float64Array.
Actually using a Float32Array passes all the tests we currently have and
reduces memory usage (by 16 bytes per op), however to be sure that it
does not introduce rounding bugs we'd need to `Math.fround` all
operations we do on the clipBox and pendingBBox. It reduces the
readibilty of the code, but we can revisit if this memory usage becomes
a problem.
When pages carry explicit pageIndices (e.g. after a delete),
resolve insertAfter against that layout instead of the empty
base sequence. Also reject partial pageIndices combined with
insertAfter, which would race against the extraction's auto-fill.
The job's environment must be `code-coverage` before it has access to
the `CODECOV_TOKEN` secret that's required for pushing coverage data to
Codecov. Without it we get an HTTP 400 response with a `Token required
because branch is protected` message if it's run from `master`.
Fixes f932a58d.
The font tests have run with coverage reporting enabled for quite some
time now and the coverage information has proven to work and be stable,
so we don't have to also run the font tests without coverage reporting
anymore, thereby reducing the total runtime of the workflow.
In practice this probably hasn't caused any bugs, however given that `DOMElement.style.zIndex` returns a string the existing code is subtly wrong.
This is also consistent with pre-existing `zIndex` code in the `PopupElement` class, see the `#show` and `#hide` methods.
Currently the hash-property is just a stringified Array, which means that the hash-property can become arbitrarily long. That's not a good idea since it's used to compute a cache-key, in the API, which is then sent to the worker-thread. Hence the hash-property should be reasonably short, and its length should *not* depend on the number of modified editors, which can be achieved by using `MurmurHash3_64` here as well.
Many `parseInt` call-sites already provide the `radix` argument, and this rule helps improve consistency in the code-base; see https://eslint.org/docs/latest/rules/radix
*Please note:* The rule is disabled in `src/scripting_api/util.js` for now, since it's not obvious at a glance (at least to me) what the correct `radix` argument should be there.
