[api-minor] Remove support for browsers/environments without fully working URL.createObjectURL implementations
#14515
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rking `URL.createObjectURL` implementations 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.
Snuffleupagus
force-pushed
the
rm-disableCreateObjectURL
branch
from
4c902eb to
dc2868d
Compare
|
/botio integrationtest |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/fc6abe6a55015e6/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/be033965c211c72/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/be033965c211c72/output.txt Total script time: 4.95 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/fc6abe6a55015e6/output.txt Total script time: 7.90 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.241.84.105:8877/586919f4036fb61/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/586919f4036fb61/output.txt Total script time: 4.31 mins Published |
timvandermeij
approved these changes
Feb 2, 2022
|
I agree with the reasons to do this; thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This
disableCreateObjectURLoption was originally introduced all the way back in PR #4103 (eight years ago), in order to work-aroundURL.createObjectURL()-bugs specific to Internet Explorer.In PR #8081 (five years ago) the
disableCreateObjectURLoption was extended to cover Google Chrome on iOS-devices as well, since that configuration apparently also suffered fromURL.createObjectURL()-bugs.[1]At this point in time, I thus think that it makes sense to re-evaluate if we should still keep the
disableCreateObjectURLoption.For Internet Explorer, support was explicitly removed in PDF.js version
2.7.570which 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
disableCreateObjectURLoption is only being used in the viewer and anyURL.createObjectURL()-bugs browser/platform bugs will thus not affect the main PDF.js library. Furthermore, given where thedisableCreateObjectURLoption 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.