[Tracking] Back-port patches to the current PDF.js pre-release (v2.4.456)

[Snuffleupagus]

One of the most significant changes in the current PDF.js pre-release, see https://github.com/mozilla/pdf.js/releases/tag/v2.4.456, is that we're now producing two kind of builds (with/without Babel translation and polyfills).

This has lead to some issues and/or support questions, since the default PDF.js builds are no longer directly compatible with "all" browsers/environments.
Hence we may want to consider back-porting only the following patches (the list below is subject to change), using git cherry-pick, to the v2.4.456 pre-release and then replace it with a new version.

• Fail early, in modern GENERIC builds, if certain required browser functionality is missing (issue 11762) #11771
• Fail early, in modern GENERIC builds, if certain required browser functionality is missing (PR 11771 follow-up) #11799
• Always attempt to dispatch the "webviewerloaded" event at the embedding document (PR 10318 follow-up, issue 11829) #11837

---

Given that the release was done less than a month ago, as of this writing, we probably want to wait a bit before making a final decision (there may be additional issues/regressions that should be addressed).

While I don't have any data and/or statistics to back up this claim, but based on experience it seems that many (most?) users will only ever use "stable" releases. Hence fixing these issues at the pre-release stage seem much simpler, rather than having them reach an actual release version (which is why I opened this tracking issue).

[timvandermeij]

Let's indeed see if more people run into problems with this before making a final decision.

[Snuffleupagus]

It's now been well over a month since the pre-release was made, and thus far no serious regressions have been reported.
The list above however contains a handful of smaller, quality-of-life improvement, patches which should help once the release becomes stable (given the apparent unwillingness of many users to test pre-releases).

I think that we should now make a decision here, either to:

• Back-port the patches listed above, and replace the pre-release.
• Close this as WONTFIX, accepting that doing so likely results in additional support requests.

[timvandermeij]

Given that it's mentioned in the release notes, I'm not how necessary it is to backport those patches. If we decide to do so, I'm not entirely sure what the process for that is. I think we can remove the current pre-release and make a new one without doing the version bump, but I'm not sure if that will mess up the releases on e.g. NPM?

/cc @brendandahl Any ideas for this?

[Snuffleupagus]

Actually, rather than messing with the existing release it might make more sense to simply just create a new "normal" one instead!?

Basically, create a new pre-release (2.5.something) and simply let 2.4.456 become the new stable release. Generally speaking it'd probably not be a bad idea to try and have slightly more frequent releases if at all possible (perhaps every 2-3 months), for a couple of reasons: Many users only seem to want to use "stable" release, and it'll reduce the time for bug-fixes to reach "stable" releases. Furthermore, it would also decrease the number of [api-minor] changes per release, possibly making updates less painful as well.

[timvandermeij]

Good plan. I'll try to do this soon since there is a demand for the new version.

[Snuffleupagus]

When the next release is done, we should also remember to revert the current special-casing at https://mozilla.github.io/pdf.js/getting_started/#download as well.