Instead of just upstreaming the changes from [bug 1345253](https://bugzilla.mozilla.org/show_bug.cgi?id=1345253) as-is, it seemed better to simply get rid of the loops altogether and use the same approach as in `PDFViewer`/`PDFThumbnailViewer`.
This patch is another step towards enabling Babel. Since we're moving
towards ES6 modules, we will not be using UMD headers anymore, so we can
remove the validation.
First of all, `compatibility.js` is already available in `lib/shared/compatibility.js`. Second of all, as can be seen in 9142301f35 (diff-9432ebaa58e10ab02874fcb86f689caa), the `lib/web/compatibility.js` file cannot work since the `require` statement isn't compatible with the output of `gulp lib`.
*This is something that I noticed while working on PR 8126, which is (more) fallout from PR 6065.*
In general, it's actually *not* correct to return `Dict.empty` as the default value for non-existent properties. Please note that a prior PR, see https://github.com/mozilla/pdf.js/pull/5957#issuecomment-103112698, asked for that behaviour but I don't think that's right.
Obviously for properties that are (or should) be `Dict`s it makes sense, however certain properties can be e.g. Strings or Arrays instead. In the latter case, returning `Dict.empty` is just plain wrong, and it's quite fascinating that this hasn't caused any errors in practice. (The existing validation in the various getters has actually saved us here.)
Also, when looking at this code again, it seemed unnecessary to duplicate the `MAX_LOOP_COUNT` check since we could just return immediately instead.
When using content security headers to restrict connections to the same origin,
you may not make connections to `example.com`. This feature detection also
works with a request to the current location.
It appears that I accidentally broke this in PR 6065, sorry about that!
The issue in this particular PDF file is that there's `/Rotate` entries on different levels of the `/Pages` tree. We're supposed to use the `/Rotate` entry in the `/Page` dict (which is `0`), but because of an incorrect condition we instead ended up with the one from the `/Pages` dict (which is `180`).
Fixes 8125.
Given that the mailing list has now been closed, see [bug 1340296](https://bugzilla.mozilla.org/show_bug.cgi?id=1340296), and that there's no weekly meetings any more, we probably shouldn't mention either of those in CONTRIBUTING.md.
Instead, let's just suggest the IRC channel as a means of communication here.
Ideally, the `Annotation` class should not have anything to do with the
page's operator list. How annotations are added to the page's operator
list is logic that belongs in `src/core/document.js` instead where the
operator list is constructed.
Moreover, some comments have been added to clarify the intent of the
code.
Even though the PDF specification does not state that `Opt` fields are
inheritable, in practice there are PDF generators that let annotations
inherit the options from a parent.
This fixes something that I noticed while working with the code in `Catalog.getPageDict` when debugging issue 8088.
Note that while I don't have an example where this patch really matters, given that e.g. `PartialEvaluator.hasBlendModes` depends on the `objId` to avoid cyclic references this patch could potentially help for some PDF files.
As discussed on IRC, we need to check all nodes at the *bottom* of the tree to ensure that we find the correct `Page` dict.
Furthermore, this patch also gets rid of the caching present in a previous version, since it's not clear if that really helps.
Note that this patch purposely adds an `eq` test, using a reduced test-case, so that we can be sure that the algorithm actually finds the correct `Page` dict for each `pageIndex`.
Fixes 8088.
The download button in pdf.js doesn't work in iOS Chrome.
- It appears to be an issue with URLs from URL.createObjectURL.
The URL is correct, but iOS Chrome won't even load the URL
when `a.click()` is called in `download_manager.js`. Even
if you manually visit the URL, you get a blank page.
- Fix this by detecting iOS Chrome and disabling createObjectURL.
The `download_manager.js` `download` method wasn't checking
`PDFJS.disableCreateObjectURL`, so check it there, too.
- Move the navigator.msSaveBlob check earlier, so that
this doesn't change IE10 / IE11 behavior.
- Remove the !URL check since pdf.js has a URL polyfill
now.
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js)
