Skip to content

[pull] master from mozilla:master#266

Merged
pull[bot] merged 8 commits intocode:masterfrom
mozilla:master
Mar 15, 2026
Merged

[pull] master from mozilla:master#266
pull[bot] merged 8 commits intocode:masterfrom
mozilla:master

Conversation

@pull
Copy link

@pull pull bot commented Mar 15, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

Snuffleupagus and others added 8 commits March 13, 2026 23:42
This is an old API-parameter that is now unused within the PDF.js project itself, and its description says that it's (partly) being used for "range requests operations".
Note that the `length` API-parameter is used to set the *initial* `contentLength` in various `BasePDFStreamReader` implementations, however it's always overridden by the "Content-Length" header (sent by the server) when that one exists *and* is a valid number. While we currently fallback to the keep the initial `contentLength` otherwise, note however how in that case range requests will always be *disabled* and thus the only spot in the code-base [where `fullReader.contentLength` is necessary](https://github.com/mozilla/pdf.js/blob/873378b71830a151d3350d812bf914b673149cd6/src/core/worker.js#L230-L236) cannot actually be reached.

Hence the only possible reason to use the `length` API-parameter would be for improved progress reporting[1] during streaming of PDF data in rare cases where the "Content-Length" header is missing/invalid, but the user *somehow* has information from another source about the correct `length` of the PDF document.
That situation feels very much like an edge-case, but it's obviously impossible to know if someone is depending on it. However, please note that there's a work-around available for users affected by this removal:
 - Implement a `PDFDataRangeTransport` instance together with custom data-fetching[2], since in that case its `length`-parameter will always be used as-is.

Finally, updates various `BasePDFStreamReader` implementations to only set the `_isRangeSupported` field once the headers are available (since previously we'd just overwrite the "initial" value anyway).

---

[1] I.e. to avoid the "indeterminate" loadingBar being displayed in the viewer.

[2] This is what e.g. the Firefox PDF Viewer uses.
Bumps [undici](https://github.com/nodejs/undici) from 7.21.0 to 7.24.2.
- [Release notes](https://github.com/nodejs/undici/releases)
- [Commits](nodejs/undici@v7.21.0...v7.24.2)

---
updated-dependencies:
- dependency-name: undici
  dependency-version: 7.24.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
…-7.24.2

Bump undici from 7.21.0 to 7.24.2
[api-minor] Remove the `length` parameter from `getDocument`
Instead of having all the code for the new debugger in a single file,
split it into multiple files.
This makes it easier to navigate and maintain the codebase.
It'll be make hacking and fixing bugs in the debugger easier.
Split the new debugger into multiple files
@pull pull bot locked and limited conversation to collaborators Mar 15, 2026
@pull pull bot added the ⤵️ pull label Mar 15, 2026
@pull pull bot merged commit 3127492 into code:master Mar 15, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants