ZenBrowserMirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/zen-browser/pdf.js.git synced 2025-07-09 01:35:43 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

[api-minor] Remove support for browsers/environments without fully working URL.createObjectURL implementations

Browse source 
This `disableCreateObjectURL` option was originally introduced all the way back in PR 4103 (eight years ago), in order to work-around `URL.createObjectURL()`-bugs specific to Internet Explorer.
In PR 8081 (five years ago) the `disableCreateObjectURL` option was extended to cover Google Chrome on iOS-devices as well, since that configuration apparently also suffered from `URL.createObjectURL()`-bugs.[1]

At this point in time, I thus think that it makes sense to re-evaluate if we should still keep the `disableCreateObjectURL` option.

 - For Internet Explorer, support was explicitly removed in PDF.js version `2.7.570` which was released one year ago and all IE-specific compatibility code (and polyfills) have since been removed.

 - For Google Chrome on iOS-devices, while we still "support" such configurations, it's *not* the focus of any development and platform-specific bugs are thus often closed as WONTFIX.

Note here that at this point in time, the `disableCreateObjectURL` option is *only* being used in the viewer and any `URL.createObjectURL()`-bugs browser/platform bugs will thus not affect the main PDF.js library. Furthermore, given where the `disableCreateObjectURL` option is being used in the viewer the basic functionality should also remain unaffected by these changes.[2]
Furthermore, it's also possible that the `URL.createObjectURL()`-bugs have been fixed in *browser* itself since PR 8081 was submitted.[3]

Obviously you could argue that this isn't a lot of code, w.r.t. number of lines, and you'd be technically correct. However, it does add additional complexity in a few different viewer components which thus add overhead when reading and working with this code.
Finally, assuming the `URL.createObjectURL()`-bugs are still present in Google Chrome on iOS-devices, I think that we should ask ourselves if it's reasonable for the PDF.js project (and its contributors) to keep attempting to support a configuration if the *browser* developers still haven't fixed these kind of bugs!?

---
[1] According to https://groups.google.com/a/chromium.org/forum/#!topic/chromium-html5/RKQ0ZJIj7c4, which is linked in PR 8081, that bug was mentioned/reported as early as the 2014 (eight years ago).

[2] Viewer functionality such as e.g. downloading and printing may be affected.

[3] I don't have access to any iOS-devices to test with.
This commit is contained in:
Jonas Jenwald 2022-01-02 13:18:18 +01:00
parent 9fba97d2f6
commit dc2868d7d1
5 changed files with 11 additions and 49 deletions
Download patch file Download diff file Expand all files Collapse all files

21
web/app.js
View file

@ -35,7 +35,7 @@ import {
SpreadMode,
TextLayerMode,
} from "./ui_utils.js";
import { AppOptions, compatibilityParams, OptionKind } from "./app_options.js";
import { AppOptions, OptionKind } from "./app_options.js";
import { AutomationEventBus, EventBus } from "./event_utils.js";
import {
build,
@ -2490,22 +2490,11 @@ if (typeof PDFJSDev === "undefined" || PDFJSDev.test("GENERIC")) {
}
const file = evt.fileInput.files[0];
if (!compatibilityParams.disableCreateObjectURL) {
let url = URL.createObjectURL(file);
if (file.name) {
url = { url, originalUrl: file.name };
}
PDFViewerApplication.open(url);
} else {
PDFViewerApplication.setTitleUsingUrl(file.name);
// Read the local file into a Uint8Array.
const fileReader = new FileReader();
fileReader.onload = function webViewerChangeFileReaderOnload(event) {
const buffer = event.target.result;
PDFViewerApplication.open(new Uint8Array(buffer));
};
fileReader.readAsArrayBuffer(file);
let url = URL.createObjectURL(file);
if (file.name) {
url = { url, originalUrl: file.name };
}
PDFViewerApplication.open(url);
};
webViewerOpenFile = function (evt) {