Prevent issues, in PDFDocument.fieldObjects, for invalid Annotations

[Snuffleupagus]

For an invalid Annotation, there's one code-path where undefined is returned from AnnotationFactory._create. That'd currently, incorrectly, trigger an error during the PDFDocument._collectFieldObjects parsing which thus seem good to avoid.
Along these lines, the filtering in PDFDocument.fieldObjects is also updated to handle both null and undefined the same way.

[Snuffleupagus]

/botio unittest

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_unittest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/71a50e868e9f893/output.txt

[pdfjsbot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.67.70.0:8877/71a50e868e9f893/output.txt

Total script time: 4.35 mins

• Unit Tests: FAILED

[calixteman]

Good catch.

[timvandermeij]

Are you sure this can actually happen? undefined is returned at https://github.com/mozilla/pdf.js/blob/master/src/core/annotation.js#L81, which can only happen if the ref in https://github.com/mozilla/pdf.js/blob/master/src/core/annotation.js#L79 is not a dictionary. However, if that were the case, it would break even before https://github.com/mozilla/pdf.js/pull/12516/files#diff-f0385d138acfe65f04aec809ad0522722883e56b6420ccb8f1d2e16b50631c1eR972, namely at https://github.com/mozilla/pdf.js/blob/master/src/core/document.js#L952-L953 as far as I can tell.

That's because the fieldRef we give to AnnotationLayer.create is the same fieldRef that we use just above to also fetch the T property, so if it's not a dictionary we wouldn't be able to call .has("T") on it.

[Snuffleupagus]

Are you sure this can actually happen?

It's more of a better safe than sorry sort of patch, since I think that it first of all makes general sense and secondly who knows what future code changes may bring. Good point though!

[timvandermeij]

Thanks!