mozilla/pdf.js + (-2) -

    *Fixes a regression from PR 15246, sorry about that!*
    The following is an overview of the changes in this patch; sorry about the size/scope of this!
    I overlooked this in PR 14886, sorry about that!
    According to MDN, see https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute#parameters, non-string values will be automatically converted into strings. I should probably have read that article more carefully, to avoid unnecessary churn in the code; sorry about that!
    I forgot about this in PR 14400, since we should obviously be consistent *and* given that the existing check is actually wrong; sorry about this!
    *Please note:* I'm sorry about the size of this patch, but given how intertwined all of this unfortunately is it just didn't seem easy to split this into smaller parts.
    In PR 14114 this was only added to the default viewer, which means that in the viewer components the user would need to *manually* implement /Lang handling. This was (obviously) a bad choice, since the viewer components already support e.g. structTrees by default; sorry about overlooking this!
    That seems quite unfortunate, since `pdfjs.enablePermissions` is off by default, and it thus seem better only do the API-call when actually needed; sorry about this!
    Given that things work just as fine as-is, let's simply remove that optional parameter for now; sorry about the churn here!
    In the second commit in PR 14295, I forgot that the pages in XFA-documents don't have references (like in regular PDF documents); sorry about that!
    *Sometimes I'll hopefully learn to optimize my code directly when writing it, rather than having to do multiple clean-up passes; sorry about the churn here!*
    In the GENERIC viewer, e.g. when dragging-and-dropping a new PDF document which automatically opens the outline, there can now be breaking errors in the `{BaseViewer, PDFThumbnailViewer}.#getScrollAhead` methods since there's no visible pages/thumbs during loading; sorry about the breakage!
    I missed this in PR 13900, sorry about that!
    Currently a `TESTING = true` environment variable will *always* take precedence in the various build-tasks, and there's no way to explicitly disable it for a particular build. That's clearly an oversight on my part, however it's easy enough to fix this; sorry about breaking this!
    The current regular expression contains a typo, leading to intermittent test-failures for certain `docId`s; sorry about that!
    This is what I ought to have done from the start, sorry about the code churn here!
    *Sorry about the churn here, since the change that I made in PR 13516 was not very smart.*
    Obviously I *should* have done this already back in PR 13074, sorry about the churn here!
    *Somehow I didn't think of this yesterday, but this feels like a much better solution overall; sorry about the churn here!*
    This is what I *should* have done in PR 12777, but for some reason didn't figure out how to implement it well enough back then; sorry about the churn here!
    As can be seen in `BaseViewer.setDocument`, it's currently necessary to *manually* delay the `PDFScriptingManager`-destruction in order for things to work correctly. This is, in hindsight, obviously an *extremely poor* design choice on my part; sorry about the churn here!
    I completely missed updating these in PR 12666; sorry about that!
    Note that a `RenderingCancelledException` *should* never actually reach this method, but better safe than sorry I suppose, considering that both `PDFPageView` and `PDFThumbnailView` are already catching `RenderingCancelledException`s since those are *not* Errors in the normal sense of the word.
    I completely overlooked the fact that we had *one* occurrence of an asynchronous `mkdirp` call in the gulpfile, which thus breaks since the package now uses Promises rather than a callback function; sorry about that!
    I overlooked this in PR 11631; sorry about that!
    Unfortunately these aren't actual `Error`s, which thus ends up unintentionally triggering the `assert` in `PDFPageProxy._abortOperatorList`; sorry about that!
    Unfortunately I forgot to test `gulp mozcentraldiff` with PR 11256, which is really bad since it will cause the en-US `chrome.properties` l10n file to be deleted at mozilla-central; sorry about breaking this!
    *This should obviously have been done in PR 11097, but for some reason I completely overlooked it; sorry about that.*
    Looking at this again, it struck me that added functionality in `Util.intersect` is probably more confusing than helpful in general; sorry about the churn in this code!
    While PR 10714 did address the `disableRange=true` case, it also managed to "break" the `disableStream=true` case instead since the indeterminate loadingBar is now displayed when it shouldn't; sorry about that!
    This contains a couple of changes that I missed elsewhere, sorry about that!
    *This was a stupid error on my part; sorry about breaking this!*
    *The danger of fixing one bug is that it can, sometimes too easily, cause another one in the process; sorry for not catching this when testing PR 9816 locally.*
    It turns out that PR 9245 unfortunately broke benchmarking completely, sorry about that!
    *I'm sorry that this became quite long, but to try and summarize:*
    It appears that I accidentally broke this in PR 6065, sorry about that!
    I missed this during review, sorry about that!
    I somehow managed miss including one of the upstream changes in PR 6489; hence this patch. Sorry about the unnecessary churn in this code!
    I'm really sorry about the churn in this code!