2017-07-01 02:59:52 +09:00
|
|
|
/* Copyright 2012 Mozilla Foundation
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2022-03-08 01:41:41 +09:00
|
|
|
import { assert, PromiseCapability } from "../shared/util.js";
|
2021-02-24 21:02:58 +09:00
|
|
|
import { isPdfFile } from "./display_utils.js";
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
/** @implements {IPDFStream} */
|
|
|
|
class PDFDataTransportStream {
|
2023-01-10 01:24:52 +09:00
|
|
|
constructor(
|
|
|
|
{
|
|
|
|
length,
|
|
|
|
initialData,
|
|
|
|
progressiveDone = false,
|
|
|
|
contentDispositionFilename = null,
|
|
|
|
disableRange = false,
|
|
|
|
disableStream = false,
|
|
|
|
},
|
|
|
|
pdfDataRangeTransport
|
|
|
|
) {
|
2020-05-05 19:40:01 +09:00
|
|
|
assert(
|
|
|
|
pdfDataRangeTransport,
|
|
|
|
'PDFDataTransportStream - missing required "pdfDataRangeTransport" argument.'
|
|
|
|
);
|
2017-07-01 02:59:52 +09:00
|
|
|
|
|
|
|
this._queuedChunks = [];
|
2023-01-10 01:24:52 +09:00
|
|
|
this._progressiveDone = progressiveDone;
|
|
|
|
this._contentDispositionFilename = contentDispositionFilename;
|
[Firefox regression] Fix `disableRange=true` bug in `PDFDataTransportStream`
Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.
Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:
- In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.
- (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.*
In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
2019-03-27 00:05:30 +09:00
|
|
|
|
2020-11-06 22:36:16 +09:00
|
|
|
if (initialData?.length > 0) {
|
[api-minor] Enable transferring of TypedArray PDF data by default (PR 15908 follow-up)
This patch removes the recently introduced `transferPdfData` API-option, and simply enables transferring of TypedArray data *by default* instead of copying it. This will help reduce main-thread memory usage, however it will take ownership of the TypedArrays. Currently this only applies to the following cases:
- TypedArrays passed to the `getDocument`-function in the API, in order to open PDF documents from binary data.
- TypedArrays passed to a `PDFDataRangeTransport`-instance, used to support custom PDF document fetching/loading (see e.g. the Firefox PDF Viewer).
*PLEASE NOTE:* To avoid being affected by this, please simply *copy* any TypedArray data before passing it to either of the functions/methods mentioned above.
Now that we transfer TypedArray data that we previously only copied, we need to be more careful with input validation. Given how the `{IPDFStreamReader, IPDFStreamRangeReader}.read` methods will always return ArrayBuffer data, which is then transferred to the worker-thread[1], the actual TypedArray data passed to the API thus need to have the same exact size as its underlying ArrayBuffer to prevent issues.
Hence we'll check for this and only allow transferring of *safe* TypedArray data, and fallback to simply copying the data just as before. This obviously shouldn't be an issue in the Firefox PDF Viewer, but for the general PDF.js library we need to be more careful here.
---
[1] See https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2492-L2506 respectively https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2578-L2590
2023-01-13 19:16:28 +09:00
|
|
|
// Prevent any possible issues by only transferring a Uint8Array that
|
|
|
|
// completely "utilizes" its underlying ArrayBuffer.
|
|
|
|
const buffer =
|
|
|
|
initialData instanceof Uint8Array &&
|
|
|
|
initialData.byteLength === initialData.buffer.byteLength
|
|
|
|
? initialData.buffer
|
|
|
|
: new Uint8Array(initialData).buffer;
|
2017-07-01 02:59:52 +09:00
|
|
|
this._queuedChunks.push(buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
this._pdfDataRangeTransport = pdfDataRangeTransport;
|
2023-01-10 01:24:52 +09:00
|
|
|
this._isStreamingSupported = !disableStream;
|
|
|
|
this._isRangeSupported = !disableRange;
|
|
|
|
this._contentLength = length;
|
2017-07-01 02:59:52 +09:00
|
|
|
|
|
|
|
this._fullRequestReader = null;
|
|
|
|
this._rangeReaders = [];
|
|
|
|
|
|
|
|
this._pdfDataRangeTransport.addRangeListener((begin, chunk) => {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._onReceiveData({ begin, chunk });
|
2017-07-01 02:59:52 +09:00
|
|
|
});
|
|
|
|
|
2019-04-06 18:04:44 +09:00
|
|
|
this._pdfDataRangeTransport.addProgressListener((loaded, total) => {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._onProgress({ loaded, total });
|
2017-07-01 02:59:52 +09:00
|
|
|
});
|
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
this._pdfDataRangeTransport.addProgressiveReadListener(chunk => {
|
|
|
|
this._onReceiveData({ chunk });
|
2017-07-01 02:59:52 +09:00
|
|
|
});
|
|
|
|
|
[Firefox regression] Fix `disableRange=true` bug in `PDFDataTransportStream`
Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.
Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:
- In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.
- (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.*
In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
2019-03-27 00:05:30 +09:00
|
|
|
this._pdfDataRangeTransport.addProgressiveDoneListener(() => {
|
|
|
|
this._onProgressiveDone();
|
|
|
|
});
|
|
|
|
|
2017-07-01 02:59:52 +09:00
|
|
|
this._pdfDataRangeTransport.transportReady();
|
|
|
|
}
|
|
|
|
|
2023-01-10 01:24:52 +09:00
|
|
|
_onReceiveData({ begin, chunk }) {
|
[api-minor] Enable transferring of TypedArray PDF data by default (PR 15908 follow-up)
This patch removes the recently introduced `transferPdfData` API-option, and simply enables transferring of TypedArray data *by default* instead of copying it. This will help reduce main-thread memory usage, however it will take ownership of the TypedArrays. Currently this only applies to the following cases:
- TypedArrays passed to the `getDocument`-function in the API, in order to open PDF documents from binary data.
- TypedArrays passed to a `PDFDataRangeTransport`-instance, used to support custom PDF document fetching/loading (see e.g. the Firefox PDF Viewer).
*PLEASE NOTE:* To avoid being affected by this, please simply *copy* any TypedArray data before passing it to either of the functions/methods mentioned above.
Now that we transfer TypedArray data that we previously only copied, we need to be more careful with input validation. Given how the `{IPDFStreamReader, IPDFStreamRangeReader}.read` methods will always return ArrayBuffer data, which is then transferred to the worker-thread[1], the actual TypedArray data passed to the API thus need to have the same exact size as its underlying ArrayBuffer to prevent issues.
Hence we'll check for this and only allow transferring of *safe* TypedArray data, and fallback to simply copying the data just as before. This obviously shouldn't be an issue in the Firefox PDF Viewer, but for the general PDF.js library we need to be more careful here.
---
[1] See https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2492-L2506 respectively https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2578-L2590
2023-01-13 19:16:28 +09:00
|
|
|
// Prevent any possible issues by only transferring a Uint8Array that
|
|
|
|
// completely "utilizes" its underlying ArrayBuffer.
|
2023-01-12 22:43:56 +09:00
|
|
|
const buffer =
|
[api-minor] Enable transferring of TypedArray PDF data by default (PR 15908 follow-up)
This patch removes the recently introduced `transferPdfData` API-option, and simply enables transferring of TypedArray data *by default* instead of copying it. This will help reduce main-thread memory usage, however it will take ownership of the TypedArrays. Currently this only applies to the following cases:
- TypedArrays passed to the `getDocument`-function in the API, in order to open PDF documents from binary data.
- TypedArrays passed to a `PDFDataRangeTransport`-instance, used to support custom PDF document fetching/loading (see e.g. the Firefox PDF Viewer).
*PLEASE NOTE:* To avoid being affected by this, please simply *copy* any TypedArray data before passing it to either of the functions/methods mentioned above.
Now that we transfer TypedArray data that we previously only copied, we need to be more careful with input validation. Given how the `{IPDFStreamReader, IPDFStreamRangeReader}.read` methods will always return ArrayBuffer data, which is then transferred to the worker-thread[1], the actual TypedArray data passed to the API thus need to have the same exact size as its underlying ArrayBuffer to prevent issues.
Hence we'll check for this and only allow transferring of *safe* TypedArray data, and fallback to simply copying the data just as before. This obviously shouldn't be an issue in the Firefox PDF Viewer, but for the general PDF.js library we need to be more careful here.
---
[1] See https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2492-L2506 respectively https://github.com/mozilla/pdf.js/blob/e09ad99973b1dcb82a06c001da96d52fc5bcab9d/src/display/api.js#L2578-L2590
2023-01-13 19:16:28 +09:00
|
|
|
chunk instanceof Uint8Array &&
|
|
|
|
chunk.byteLength === chunk.buffer.byteLength
|
2023-01-12 22:43:56 +09:00
|
|
|
? chunk.buffer
|
|
|
|
: new Uint8Array(chunk).buffer;
|
2023-01-10 01:24:52 +09:00
|
|
|
|
|
|
|
if (begin === undefined) {
|
[Firefox regression] Fix `disableRange=true` bug in `PDFDataTransportStream`
Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.
Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:
- In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.
- (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.*
In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
2019-03-27 00:05:30 +09:00
|
|
|
if (this._fullRequestReader) {
|
2019-05-16 15:55:52 +09:00
|
|
|
this._fullRequestReader._enqueue(buffer);
|
|
|
|
} else {
|
|
|
|
this._queuedChunks.push(buffer);
|
2017-07-01 02:59:52 +09:00
|
|
|
}
|
2019-05-16 15:55:52 +09:00
|
|
|
} else {
|
2020-04-14 19:28:14 +09:00
|
|
|
const found = this._rangeReaders.some(function (rangeReader) {
|
2023-01-10 01:24:52 +09:00
|
|
|
if (rangeReader._begin !== begin) {
|
2019-05-16 15:55:52 +09:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
rangeReader._enqueue(buffer);
|
|
|
|
return true;
|
|
|
|
});
|
2020-05-05 19:40:01 +09:00
|
|
|
assert(
|
|
|
|
found,
|
|
|
|
"_onReceiveData - no `PDFDataTransportStreamRangeReader` instance found."
|
|
|
|
);
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
get _progressiveDataLength() {
|
2021-01-20 00:28:47 +09:00
|
|
|
return this._fullRequestReader?._loaded ?? 0;
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
_onProgress(evt) {
|
|
|
|
if (evt.total === undefined) {
|
|
|
|
// Reporting to first range reader, if it exists.
|
2022-09-21 23:47:36 +09:00
|
|
|
this._rangeReaders[0]?.onProgress?.({ loaded: evt.loaded });
|
2019-05-16 15:55:52 +09:00
|
|
|
} else {
|
2022-09-21 23:47:36 +09:00
|
|
|
this._fullRequestReader?.onProgress?.({
|
|
|
|
loaded: evt.loaded,
|
|
|
|
total: evt.total,
|
|
|
|
});
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
_onProgressiveDone() {
|
2022-09-05 22:36:04 +09:00
|
|
|
this._fullRequestReader?.progressiveDone();
|
2019-05-16 15:55:52 +09:00
|
|
|
this._progressiveDone = true;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
_removeRangeReader(reader) {
|
|
|
|
const i = this._rangeReaders.indexOf(reader);
|
|
|
|
if (i >= 0) {
|
|
|
|
this._rangeReaders.splice(i, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
getFullReader() {
|
2020-05-05 19:40:01 +09:00
|
|
|
assert(
|
|
|
|
!this._fullRequestReader,
|
|
|
|
"PDFDataTransportStream.getFullReader can only be called once."
|
|
|
|
);
|
2019-05-16 15:55:52 +09:00
|
|
|
const queuedChunks = this._queuedChunks;
|
|
|
|
this._queuedChunks = null;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return new PDFDataTransportStreamReader(
|
|
|
|
this,
|
|
|
|
queuedChunks,
|
2021-02-24 21:02:58 +09:00
|
|
|
this._progressiveDone,
|
|
|
|
this._contentDispositionFilename
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
);
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
getRangeReader(begin, end) {
|
|
|
|
if (end <= this._progressiveDataLength) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
const reader = new PDFDataTransportStreamRangeReader(this, begin, end);
|
|
|
|
this._pdfDataRangeTransport.requestDataRange(begin, end);
|
|
|
|
this._rangeReaders.push(reader);
|
|
|
|
return reader;
|
|
|
|
}
|
|
|
|
|
|
|
|
cancelAllRequests(reason) {
|
2022-09-05 22:36:04 +09:00
|
|
|
this._fullRequestReader?.cancel(reason);
|
|
|
|
|
2021-04-24 19:36:01 +09:00
|
|
|
for (const reader of this._rangeReaders.slice(0)) {
|
|
|
|
reader.cancel(reason);
|
|
|
|
}
|
2019-05-16 15:55:52 +09:00
|
|
|
this._pdfDataRangeTransport.abort();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/** @implements {IPDFStreamReader} */
|
|
|
|
class PDFDataTransportStreamReader {
|
2021-02-24 21:02:58 +09:00
|
|
|
constructor(
|
|
|
|
stream,
|
|
|
|
queuedChunks,
|
|
|
|
progressiveDone = false,
|
|
|
|
contentDispositionFilename = null
|
|
|
|
) {
|
2017-07-01 02:59:52 +09:00
|
|
|
this._stream = stream;
|
[Firefox regression] Fix `disableRange=true` bug in `PDFDataTransportStream`
Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.
Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:
- In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.
- (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.*
In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
2019-03-27 00:05:30 +09:00
|
|
|
this._done = progressiveDone || false;
|
2021-02-24 21:02:58 +09:00
|
|
|
this._filename = isPdfFile(contentDispositionFilename)
|
|
|
|
? contentDispositionFilename
|
|
|
|
: null;
|
2017-07-01 02:59:52 +09:00
|
|
|
this._queuedChunks = queuedChunks || [];
|
2019-03-28 01:54:05 +09:00
|
|
|
this._loaded = 0;
|
|
|
|
for (const chunk of this._queuedChunks) {
|
|
|
|
this._loaded += chunk.byteLength;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
this._requests = [];
|
|
|
|
this._headersReady = Promise.resolve();
|
|
|
|
stream._fullRequestReader = this;
|
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
this.onProgress = null;
|
2017-07-01 02:59:52 +09:00
|
|
|
}
|
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
_enqueue(chunk) {
|
|
|
|
if (this._done) {
|
|
|
|
return; // Ignore new data.
|
|
|
|
}
|
|
|
|
if (this._requests.length > 0) {
|
|
|
|
const requestCapability = this._requests.shift();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
requestCapability.resolve({ value: chunk, done: false });
|
2019-05-16 15:55:52 +09:00
|
|
|
} else {
|
|
|
|
this._queuedChunks.push(chunk);
|
|
|
|
}
|
|
|
|
this._loaded += chunk.byteLength;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get headersReady() {
|
|
|
|
return this._headersReady;
|
|
|
|
}
|
2018-01-17 00:24:36 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get filename() {
|
|
|
|
return this._filename;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get isRangeSupported() {
|
|
|
|
return this._stream._isRangeSupported;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get isStreamingSupported() {
|
|
|
|
return this._stream._isStreamingSupported;
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get contentLength() {
|
|
|
|
return this._stream._contentLength;
|
|
|
|
}
|
[Firefox regression] Fix `disableRange=true` bug in `PDFDataTransportStream`
Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.
Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:
- In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.
- (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.*
In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
2019-03-27 00:05:30 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
async read() {
|
|
|
|
if (this._queuedChunks.length > 0) {
|
|
|
|
const chunk = this._queuedChunks.shift();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return { value: chunk, done: false };
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
if (this._done) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return { value: undefined, done: true };
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
2022-03-08 01:41:41 +09:00
|
|
|
const requestCapability = new PromiseCapability();
|
2019-05-16 15:55:52 +09:00
|
|
|
this._requests.push(requestCapability);
|
|
|
|
return requestCapability.promise;
|
|
|
|
}
|
|
|
|
|
|
|
|
cancel(reason) {
|
|
|
|
this._done = true;
|
2021-04-24 19:36:01 +09:00
|
|
|
for (const requestCapability of this._requests) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
requestCapability.resolve({ value: undefined, done: true });
|
2021-04-24 19:36:01 +09:00
|
|
|
}
|
2021-04-24 19:52:09 +09:00
|
|
|
this._requests.length = 0;
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
progressiveDone() {
|
|
|
|
if (this._done) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
this._done = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/** @implements {IPDFStreamRangeReader} */
|
|
|
|
class PDFDataTransportStreamRangeReader {
|
|
|
|
constructor(stream, begin, end) {
|
2017-07-01 02:59:52 +09:00
|
|
|
this._stream = stream;
|
|
|
|
this._begin = begin;
|
|
|
|
this._end = end;
|
|
|
|
this._queuedChunk = null;
|
|
|
|
this._requests = [];
|
|
|
|
this._done = false;
|
|
|
|
|
|
|
|
this.onProgress = null;
|
|
|
|
}
|
2019-05-16 15:55:52 +09:00
|
|
|
|
|
|
|
_enqueue(chunk) {
|
|
|
|
if (this._done) {
|
|
|
|
return; // ignore new data
|
|
|
|
}
|
|
|
|
if (this._requests.length === 0) {
|
|
|
|
this._queuedChunk = chunk;
|
|
|
|
} else {
|
|
|
|
const requestsCapability = this._requests.shift();
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
requestsCapability.resolve({ value: chunk, done: false });
|
2021-04-24 19:36:01 +09:00
|
|
|
for (const requestCapability of this._requests) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
requestCapability.resolve({ value: undefined, done: true });
|
2021-04-24 19:36:01 +09:00
|
|
|
}
|
2021-04-24 19:52:09 +09:00
|
|
|
this._requests.length = 0;
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
this._done = true;
|
|
|
|
this._stream._removeRangeReader(this);
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
2019-05-16 15:55:52 +09:00
|
|
|
get isStreamingSupported() {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
async read() {
|
|
|
|
if (this._queuedChunk) {
|
|
|
|
const chunk = this._queuedChunk;
|
|
|
|
this._queuedChunk = null;
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return { value: chunk, done: false };
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
|
|
|
if (this._done) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
return { value: undefined, done: true };
|
2019-05-16 15:55:52 +09:00
|
|
|
}
|
2022-03-08 01:41:41 +09:00
|
|
|
const requestCapability = new PromiseCapability();
|
2019-05-16 15:55:52 +09:00
|
|
|
this._requests.push(requestCapability);
|
|
|
|
return requestCapability.promise;
|
|
|
|
}
|
|
|
|
|
|
|
|
cancel(reason) {
|
|
|
|
this._done = true;
|
2021-04-24 19:36:01 +09:00
|
|
|
for (const requestCapability of this._requests) {
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
requestCapability.resolve({ value: undefined, done: true });
|
2021-04-24 19:36:01 +09:00
|
|
|
}
|
2021-04-24 19:52:09 +09:00
|
|
|
this._requests.length = 0;
|
2019-05-16 15:55:52 +09:00
|
|
|
this._stream._removeRangeReader(this);
|
|
|
|
}
|
|
|
|
}
|
2017-07-01 02:59:52 +09:00
|
|
|
|
Enable auto-formatting of the entire code-base using Prettier (issue 11444)
Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes).
Prettier is being used for a couple of reasons:
- To be consistent with `mozilla-central`, where Prettier is already in use across the tree.
- To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters.
Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some).
Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long.
*Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit.
(On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
|
|
|
export { PDFDataTransportStream };
|