This patch updates the minimum supported browsers as follows:
- Google Chrome 92, which was released on 2021-07-20; see https://support.google.com/chrome/a/answer/10314655
Note that nowadays we usually try, where feasible and possible, to support browsers that are about two years old. By limiting support to only "recent" browsers we reduce the risk of holding back improvements of the *built-in* Firefox PDF Viewer, and also (significantly) reduce the maintenance/support burden for the PDF.js contributors.
*Please note:* As always, the minimum supported browser version assumes that a `legacy`-build of the PDF.js library is being used; see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
- Remove the dependency on fit-curve;
- Improve the way to draw the current line in using a Path2D and
in clearing only the last part of the curve instead of clearing
all the canvas;
- Smooth the curve when drawing to avoid to have some changes after
the drawing ends;
- Make the smoothing a bit less agressive.
Originally the `PDFSidebarResizer` class was slightly larger, since the code used to contain e.g. feature testing for older (and no longer supported) browsers.
Given that there's some amount of overlap, when it comes to what DOM-elements and state that these classes need, it now seems reasonable to simply move the sidebar-resizing into the `PDFSidebar` class.
For the MOZCENTRAL build-target this patch reduces the size of the *built* `web/viewer.js` file by just over `1.1` kilobytes.
This patch updates the minimum supported browsers as follows:
- Safari 15.4, which was released on 2022-03-15; see https://en.wikipedia.org/wiki/Safari_version_history#Safari_15
Nowadays we usually we try, where feasible and possible, to support browsers that are about two years old. The reasons for limiting support to a *somewhat* more recent Safari version include:
- Throughout the history of the PDF.js project, Safari has always been the worst browser to attempt to support. Compared to other browsers there's a disproportionate number of bugs affecting Safari, especially on iOS, and in most cases those are browser-specific issues that we simply cannot address.[1]
- Safari has often been a lot slower, compared to other browsers, at implementing new web-platform features. Historically this has sometimes blocked usage of new features, for the benefit of the Firefox PDF Viewer, and it's very often meant having to include and maintain polyfills *only* for Safari.
- The current (minimum) supported Safari version lack enough functionality that polyfills placed in the `src/shared/compatibility.js` file are unfortunately not sufficient, but it also requires a bunch of special-cases in both the `gulpfile` and in the `web/`-code.
- Given that the *built-in* Firefox PDF Viewer is the primary development target for the PDF.js library, and the general development pace these days, we need to limit the maintenance "overhead" caused by other browsers.
---
[1] In a few cases a work-around might be possible, however it'd negatively affect e.g. performance, readability, and/or maintainability of the code.
For some time these checks have only targeted Node.js environments, since the features in question exist in all supported browsers (even when a `legacy`-build is used).
Now that we've updated the minimum supported Node.js version to 18, a number of polyfills are thus (finally) no longer necessary in that environment. Hence for certain *basic* functionality, such as e.g. text-extraction, it's now possible to use either a modern- or a `legacy`-build of the PDF.js library in Node.js environments.
*Please note:* For e.g. canvas-rendering in Node.js environments it's still necessary to use a `legacy`-build, since that functionality requires various polyfills.
This patch updates the minimum supported environments as follows:
- Node.js 18, which was released on 2022-04-19; see https://en.wikipedia.org/wiki/Node.js#Releases
Note also that Node.js 16 will soon reach EOL, and thus no longer receive any security updates.
This commit migrates this functionality away from the bots. Nowadays
it's possible to build and deploy the website to GitHub Pages directly
through the GitHub Actions, which provides a nice simplication of the
process. Not only does this remove the requirement to have a `gh-pages`
branch in the repository, it also avoids the complexity of having to
configure the workflow to commit to Git branches and allows us to remove
the Git committing code from the Gulpfile.
Note that deploying directly though GitHub Actions workflows needs to be
enabled in the repository settings, but this is easy and well documented
on the link below.
The following resources are relevant for this patch:
- Enabling deployment to GitHub Pages directly through GitHub Actions:
https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#publishing-with-a-custom-github-actions-workflow
- Uploading GitHub Pages artifacts example:
https://github.com/actions/upload-pages-artifact#usage
- Deploying GitHub Pages artifacts example:
https://github.com/actions/deploy-pages#usage
The `pdfjs-dist/lib/` directory contains a README file that explicitly advises against using those files, however based on a fairly large number of issues filed over the years users seem to be (mostly) overlooking that warning.
In particular it unfortunately seems to be somewhat common for users to attempt to "combine" proper builds from `pdfjs-dist/build/` together with individual components from the `pdfjs-dist/lib/web/` directory, which more often than not leads to subtle bugs and general problems.
When we receive bug reports about this it's often not immediately obvious what the problem is, given that many issues lack enough details (such as runnable test-cases), but after some back-and-forth it usually turns out that usage of `pdfjs-dist/lib/` is the culprit.
Considering that keeping the general PDF.js library working is challenging and time-consuming enough nowadays, this patch thus proposes that we stop including the "lib"-build in the `pdfjs-dist` repository to both reduce user confusion and the support burden.
The latest version of `eslint-plugin-mozilla` removed the Prettier dependency, see https://bugzilla.mozilla.org/show_bug.cgi?id=1677562, which means that we no longer need to use `npm install --force` in the PDF.js library.
After the previous patch we now have only *a single* `PRODUCTION` occurrence in the entire code-base, more specifically in the `web/viewer.html` file.
This special build-target can be replaced with any condition that always evaluate to `false`, such as e.g. a comment.
*Please note:* This patch might be considered too hacky, hence I completely understand if it's rejected.
Currently `float: inline-start/inline-end` is only supported in Firefox, see https://developer.mozilla.org/en-US/docs/Web/CSS/float#browser_compatibility, and in order to support other browsers we're thus forced to jump through some hoops.
This leads to slightly less nice code in the *built-in* Firefox PDF Viewer, and this patch attempts to improve the current situation:
- Use Stylelint to forbid direct use of `float: inline-start/inline-end` in the CSS files, to prevent future bugs in the general PDF.js viewer.
- Do a build-time replacement, only in MOZCENTRAL builds, to replace the CSS-variables with raw `float: inline-start/inline-end` instances.
The patch changes the minimum supported version of Google Chrome as follows:
- Chrome 88, which was released on 2021-01-19; see https://en.wikipedia.org/wiki/Google_Chrome_version_history
This is done to allow use of modern CSS features, such as e.g. `:is()` and `:where()` in the code-base.
When installing the PDF.js project itself it's currently necessary to use `--force` in order for all packages to install correctly, see issue 15429, hence the same is also necessary when using the `gulp dist-install` command for local development/testing.
This patch updates the minimum supported environments as follows:
- Node.js 16, which was released on 2021-04-20; see https://en.wikipedia.org/wiki/Node.js#Releases
Note also that Node.js 14 will very soon reach EOL, and thus no longer receive any security updates.
This further extends the web-specific import maps introduced in PR 16009, to allow removing *most* of the build-time `require` statements from the viewer. The few remaining ones are fallbacks used for the COMPONENTS respectively the `legacy` GENERIC builds.
After the compatibility updates in PR 15968 it's no longer strictly necessary to build the `viewer.css` file in order for the *development viewer* to work in Chromium-based browsers.
*Please note:* Given that Chromium-based browsers still don't support the *unprefixed* `mask-image` property the icons won't look right, however the development viewer itself works.
Given that Firefox is the *primary* development target, and that running `gulp generic` locally will generate polyfilled CSS, it seems reasonable to make this simplification here.
Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1]
The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer.
The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes.
---
[1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
Fewer dependencies shouldn't be a bad idea in general, and given that the `node-canvas` package already include a `DOMMatrix` polyfill we can simply use that one instead.
In the `legacy`-builds we (obviously) support the currently maintained Firefox ESR version, and looking at the [release history](https://wiki.mozilla.org/Release_Management/Calendar) those are officially supported (by Mozilla) for about 1-1.5 years.
However, for non-Firefox browsers the `legacy`-builds currently attempt to "support" browsers that are approximately *three* years old.[1] Historically, in the PDF.js project, trying to support old browsers have caused some maintenance problems and even delayed adoption of new web-platform features/functionality.
To lessen the support burden, given that the primary purpose of the PDF.js library is still to develop the *built-in* Firefox PDF Viewer, this patch proposes that the upcoming *major* release changes the minimum supported browsers/environments as follows:
- Chrome 85, which was released on 2020-08-25; see https://en.wikipedia.org/wiki/Google_Chrome_version_history
- Firefox ESR (as before); see https://wiki.mozilla.org/Release_Management/Calendar
- Safari 14, which was released on 2020-09-16; see https://en.wikipedia.org/wiki/Safari_version_history#Safari_14
- Node.js 14 (as before), which is now explicitly listed to prevent it from accidentally breaking; see https://en.wikipedia.org/wiki/Node.js#Releases
---
[1] In older browsers some functionality may not be available and generally we'll ask users to update to a modern browser when bugs, specific to old browsers, are being reported.
The [official Chrome extension](https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm) has unfortunately not been updated for *three years*, which means that it's currently missing out on years worth of bug fixes, performance improvements, and new features.
In particular, the Chrome extension suffers from a known bug with non-embedded standard fonts; see issue 13669 for details.
For the time being, this patch proposes that we *temporary* make the following changes:
- Remove the mention of the official Chrome extension from the main README, since it seems unfortunate to somewhat prominently recommend users an old and partially non-working extension.
- Don't run the `gulp lint-chromium` task as part of the CI, since in addition to the official extension not having been updated its code is also not being actively maintained.[1]
Once the official Chrome extension has been updated, and it's being actively maintained again, this patch should be simple enough to revert.
---
[1] The last commits, which aren't e.g. linting or general code-maintenance related, happened a year ago now.
Given that the official Bower website, since almost five years, has been advising users to utilize other tools it doesn't seem entirely necessary to keep including the `bower.json` file in the `pdfjs-dist` repository; see e.g. https://bower.io/blog/2017/how-to-migrate-away-from-bower/
Currently we simply use the Babel `preset-env` in the `legacy`-builds of the PDF.js library. This has the side-effect of transpiling the code for *very old* browsers/environments, including ones that we (since many years) no longer support which unnecessarily bloats the size of the `legacy`-builds.
For the CSS files we're only targeting *the supported browsers*, and it's thus possible to extend that to also apply to Babel.
One of the most significant changes, with this patch, is that we'll no longer polyfill `async`/`await` in the `legacy`-builds. However, this shouldn't be an issue given the browsers that we currently support in PDF.js; please refer to:
- https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#browser_compatibility
Note that these cases, which are all in older code, were found using the [`unicorn/no-for-loop`](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-for-loop.md) ESLint plugin rule.
However, note that I've opted not to enable this rule by default since there's still *some* cases where I do think that it makes sense to allow "regular" for-loops.
Rather than including all of this external code in the PDF.js repository, we should be using the npm package instead.
Unfortunately this is slightly more complicated than you'd hope, since the `fit-curve` package (which is older) isn't directly compatible with modern JavaScript modules.
In particular, the following cases needed to be considered:
- For the development viewer (i.e. `gulp server`) and the unit-tests, we thus need to build a fitCurve-bundle that can be directly `import`ed.
- For the actual PDF.js build-targets, we can slightly reduce the sizes by depending on the "raw" `fit-curve` source-code.
- For the Node.js unit-tests, the `fit-curve` package can be used as-is.
