Commit Graph

13543 Commits

Author SHA1 Message Date
Tim van der Meij
8ccd9eac3d
Merge pull request #12965 from Snuffleupagus/ObjectLoader-errors
Request all data, rather than throwing, when encountering general errors in `ObjectLoader._walk` (issue 9462, PR 3289 follow-up)
2021-02-06 19:38:04 +01:00
Tim van der Meij
6263a21fb5
Merge pull request #12961 from Snuffleupagus/web-optional-chaining
Use optional chaining, where possible, in the `web/`-folder
2021-02-06 19:27:15 +01:00
Tim van der Meij
d2a21a1171
Merge pull request #12941 from justinribeiro/resolve-button-aria-expanded
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and aria-controls state
2021-02-06 19:16:48 +01:00
Jonas Jenwald
d3e65f24e3 Request all data, rather than throwing, when encountering general errors in ObjectLoader._walk (issue 9462, PR 3289 follow-up)
*As far as I can tell, this has been broken ever since PR 3289 (back in 2013) without anyone noticing.*

For any non-`MissingDataException` errors encountered in `ObjectLoader._walk`, we're simply throwing immediately which thus has the potential to *completely* break rendering of an entire page.
In practice this is obviously only an issue for PDF documents which are in one way or another corrupt, since that's the only way that `XRef.fetch` will throw non-`MissingDataException` errors. To make matters worse these errors are *intermittent*, since they can only occur if the document is still loading when the `ObjectLoader`-code runs (note the early return in `ObjectLoader.load`).

Please note that we cannot simply catch the error and let "normal" parsing continue in `ObjectLoader._walk`, since that could lead to errors elsewhere given that resources "below" the current one (in the graph) might not be checked as intended then.
All-in-all, the only way to make absolutely sure that we won't cause *unexpected* `MissingDataException`s somewhere else in the code-base is to fallback to fetching the *entire* document in this edge-case.
2021-02-06 14:33:50 +01:00
Justin Ribeiro
374da648dd
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and
aria-controls state

In testing, screen readers such as JAWS have trouble understanding the expanded state of the buttons that expand hidden menus due to lacking aria-expanded attribute. Also, given that the buttons do not contain the controlled/shown element, they should also define the aria-controls attribute with associated element id per https://www.w3.org/TR/wai-aria-1.1/#aria-expanded

This fixes adds these requirements for the sidebar, find, and secondary toolbar buttons.
2021-02-05 16:08:29 -08:00
Brendan Dahl
a392082e30
Merge pull request #12944 from calixteman/xfa_config
XFA -- Update config object
2021-02-05 15:06:09 -08:00
Brendan Dahl
a447d05292
Merge pull request #11647 from Snuffleupagus/notifyPagesLoaded
[Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553)
2021-02-05 14:04:27 -08:00
Jonas Jenwald
08c23c12dc [Firefox] Block the "load" event until all pages are loaded, to ensure that printing works (bug 1618553) 2021-02-05 22:01:57 +01:00
Brendan Dahl
69ed0e9230
Merge pull request #12946 from calixteman/xfa_template
XFA -- Add template object
2021-02-05 11:21:00 -08:00
Calixte Denizet
9d47e69771 XFA -- Update config object 2021-02-05 19:22:51 +01:00
Jonas Jenwald
063a072742 Use optional chaining, where possible, in the web/-folder
By using optional chaining, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining, it's possible to reduce unnecessary code-repetition in many cases.
2021-02-05 17:50:11 +01:00
Jonas Jenwald
dc19965d78 Slightly re-factor how the BaseViewer/PDFThumbnailViewer handle page labels internally, to make the null default value clearer
Currently it's not *immediately* clear from the code itself, unless you look at the definition of `this._pageLabels`, that the default value is `null`.[1]
We can improve this, and also reduce the amount of code, by using modern ECMAScript features such as optional chaining and nullish coalescing.

---
[1] Keep in mind that an *empty* string is actually a valid page label, according to the PDF specification.
2021-02-05 17:50:07 +01:00
Tim van der Meij
094e0b2239
Merge pull request #12956 from Snuffleupagus/Puppeteer-7
Update Puppeteer to version 7
2021-02-04 23:55:50 +01:00
Jonas Jenwald
fd4e76a7e3 Update Puppeteer to version 7
Please see:
 - https://github.com/puppeteer/puppeteer/releases/tag/v7.0.1
 - https://github.com/puppeteer/puppeteer/releases/tag/v7.0.0
2021-02-04 18:03:11 +01:00
Calixte Denizet
652ff57897 XFA -- Add template object
- Specifications: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.364.2157&rep=rep1&type=pdf#page=596
2021-02-03 21:05:10 +01:00
Tim van der Meij
27ffbdf7df
Merge pull request #12952 from Snuffleupagus/issue-12951
Don't focus the `PasswordPrompt` input-field on load, when the viewer is embedded in e.g. an `iframe` (issue 12951)
2021-02-03 20:52:38 +01:00
Brendan Dahl
0d85de980b
Merge pull request #12954 from calixteman/xfa_attrs
XFA -- Add attributes and children in XFAObject
2021-02-03 11:45:45 -08:00
Calixte Denizet
7e0554afe2 XFA -- Add attributes and children in XFAObject
- in order to evaluate SOM expressions nodes and their attributes must be checked in the same order as in the xml;
 - add an object XFAObjectArray with a parameter max to handle multiple children with the same name.
2021-02-03 18:56:00 +01:00
Jonas Jenwald
d1586bbbe7 Don't focus the PasswordPrompt input-field on load, when the viewer is embedded in e.g. an iframe (issue 12951)
Given that we don't focus the viewer *itself* (among other things) when the viewer is embedded, I suppose that it makes some sense to not focus the `PasswordPrompt` input-field either on load.
In order to improve the overall UX here, if an *incorrect* password was provided we'll still focus the input-field.

Fixes 12951 (assuming we care to do so, of course).
2021-02-03 15:48:40 +01:00
Tim van der Meij
86a4ba55c5
Merge pull request #12947 from Snuffleupagus/Puppeteer-6
Update Puppeteer to version 6 (issue 12945)
2021-02-02 23:18:08 +01:00
Tim van der Meij
7a765343e4
Merge pull request #12943 from Snuffleupagus/issue-6961-test
Re-enable the `issue6961` test-case (issue 7112)
2021-02-02 23:15:59 +01:00
Jonas Jenwald
003965e1e8 Update Puppeteer to version 6 (issue 12945)
Please see https://github.com/puppeteer/puppeteer/releases/tag/v6.0.0
2021-02-02 13:18:22 +01:00
Jonas Jenwald
cacb1cc7ba Re-enable the issue6961 test-case (issue 7112) 2021-02-02 10:31:16 +01:00
Brendan Dahl
e16c99fc02
Merge pull request #12879 from calixteman/xfa_parser
XFA - Add a parser for XFA files
2021-02-01 18:34:39 -08:00
Calixte Denizet
0ff5cd7eb5 XFA - Add a parser for XFA files
- the parser is base on a class extending XMLParserBase
 - it handle xml namespaces:
   * each namespace is assocated with a builder
   * builder builds nodes belonging to the namespace
   * when a node is inserted in the parent namespace compatibility is checked (if required)
 - to avoid name collision between xml names and object properties, use Symbol.
2021-02-01 13:45:31 +01:00
Tim van der Meij
c92011e093
Merge pull request #12935 from Snuffleupagus/fullscreen-MOZCENTRAL-rm-prefixes
Remove prefixed fullscreen properties/methods from the MOZCENTRAL builds
2021-01-31 14:20:50 +01:00
Jonas Jenwald
1c802e0e6c Remove prefixed fullscreen properties/methods from the MOZCENTRAL builds
The unprefixed version of the fullscreen API has been enabled for quite some time in Firefox, see below, hence we can (slightly) clean-up the relevant code.

 - https://developer.mozilla.org/en-us/docs/Web/API/Document/fullscreenEnabled#browser_compatibility
 - https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullScreen#browser_compatibility
2021-01-31 13:45:14 +01:00
Tim van der Meij
59f938d073
Merge pull request #12933 from Snuffleupagus/rm-CSS-variables-polyfill
Stop polyfilling CSS variables in GENERIC builds
2021-01-30 16:00:55 +01:00
Jonas Jenwald
619e1d8bcf Stop polyfilling CSS variables in GENERIC builds
At this point in time, all browsers that we support have native support for CSS variables; please see https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#browser_compatibility and 9af8501e6c/gulpfile.js (L79-L91)

This reduces the size of the *built* `viewer.css` file, in GENERIC builds, from `93 814` to `55 285` bytes (~41 percent).
2021-01-30 15:38:07 +01:00
Tim van der Meij
9af8501e6c
Merge pull request #12932 from Snuffleupagus/rm-ms-prefix
Stop including `-ms` prefixed CSS rules in GENERIC builds
2021-01-30 14:36:35 +01:00
Jonas Jenwald
88ca213399 Stop including -ms prefixed CSS rules in GENERIC builds
Given that IE 11/Edge is now unsupported in PDF.js, and that Microsoft Edge is now a Chromium-browser, we can avoid (some) unnecessary bloat in the built CSS files.
2021-01-30 14:00:04 +01:00
Tim van der Meij
31b78921ca
Merge pull request #12931 from Snuffleupagus/errorFontLoadNative-no-fallback-bar
Stop showing the fallback bar for "errorFontLoadNative" errors (PR 10539 follow-up)
2021-01-29 22:04:28 +01:00
Jonas Jenwald
fec8c4c43f Access this._onUnsupportedFeature directly in FontFaceObject.getPathGenerator
Given that `FontFaceObject` is not exposed in the public API, but only accessed internally, there's no need to assume that a `FontFaceObject`-instance is ever initialized without `onUnsupportedFeature` being provided. This is also consistent with the `BaseFontLoader` implementation.
2021-01-29 16:48:55 +01:00
Jonas Jenwald
5a522a5c71 Stop showing the fallback bar for "errorFontLoadNative" errors (PR 10539 follow-up)
With PR 10539, we'll now always attempt to fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). Generally speaking, these errors are the result of insufficient validation in the PDF.js font code, however in almost all cases we've seen thus far our built-in font renderer manages just fine.
However, we still trigger the `onUnsupportedFeature` reporting, which in Firefox causes the fallback bar to be displayed. Given that, in a majority of cases[1], things look fine it seems unfortunate to bother the user with the fallback bar here.

Note that even though we no longer show the fallback bar in this case, we still report telemetry as before.

---
[1] The only *known* case where things aren't fine with the built-in font renderer is issue 10232, however that document is sufficiently broken that there's a couple of other things that will trigger the fallback bar.
2021-01-29 16:48:51 +01:00
Tim van der Meij
d6de6ea0fa
Merge pull request #12920 from roiLeo/patch-1
fix(acroforms): pdf path in acroforms example
2021-01-28 23:53:24 +01:00
Tim van der Meij
e4e92d10e8
Merge pull request #12922 from Snuffleupagus/getTextContent-globalImageCache
Ignore globally cached images in `PartialEvaluator.getTextContent` (PR 11930 follow-up)
2021-01-28 23:44:10 +01:00
Tim van der Meij
8805614a03
Merge pull request #12924 from brendandahl/fix-clone
Fix font data clone error when pdfBug is enabled.
2021-01-28 23:42:12 +01:00
Jonas Jenwald
72da2aa166 Ignore globally cached images in PartialEvaluator.getTextContent (PR 11930 follow-up)
Given that we'll only cache `/XObject`s of the `Image`-type globally, we can utilize that in `PartialEvaluator.getTextContent` as well. This way, in cases such as e.g. issue 12098, we can avoid having to fetch/parse `/XObject`s that we already know to be `Image`s. This is helpful, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general.

Also, skip a redundant `RefSetCache.has` check in the `GlobalImageCache.getData` method.
2021-01-28 10:19:26 +01:00
Brendan Dahl
52fb5abb0b Fix font data clone error when pdfBug is enabled.
The widths property should be an object to match what metrics returns.

In ZapfDingbats.pdf I was getting a data clone error with pdfBug enabled.
In buildCharCodeToWidth() there was an encoding with the name "at" which
is also the name of a method on an array. buildCharCodeToWidth assumes an
object is passed in, so when it checked for the "at" property, it found the
method and copied it over.

This only seemed to affect Firefox.
2021-01-27 14:38:43 -08:00
Tim van der Meij
d52e5b0505
Merge pull request #12903 from Snuffleupagus/GlobalImageCache-byteSize
Improve global image caching for small images (PR 11912 follow-up, issue 12098)
2021-01-27 22:20:58 +01:00
Tim van der Meij
286271152f
Merge pull request #12910 from calixteman/bidi
Add back dir property in spans in text layer
2021-01-27 22:09:00 +01:00
roiLeo
7c4d751ea9
fix(acroforms): pdf path in acroforms example 2021-01-27 11:12:36 +01:00
Tim van der Meij
639437d287
Merge pull request #12911 from calixteman/reg_test
Fix text layer regression tests in using the correct line-height property
2021-01-26 23:45:45 +01:00
Tim van der Meij
d850773360
Merge pull request #12916 from Snuffleupagus/dist-sandbox
Include `pdf.sandbox.js` when building the pdfjs-dist files
2021-01-26 23:42:47 +01:00
Jonas Jenwald
85a4bc85e7 Include pdf.sandbox.js when building the pdfjs-dist files
Currently it's missing in pdfjs-dist, however that's not a big issue considering that it's broken in non-TESTING builds before PR 12914 anyway.
2021-01-26 16:34:19 +01:00
calixteman
465697eb10
JS - QuickJS sandbox initialization must be the last evaluated string (#12914)
- aims to fix issue #12912
2021-01-26 14:56:01 +01:00
Jonas Jenwald
1ab6d2c604 Improve global image caching for small images (PR 11912 follow-up, issue 12098)
When implementing the `GlobalImageCache` functionality I was mostly worried about the effect of *very large* images, hence the maximum number of cached images were purposely kept quite low[1].
However, there's one fairly obvious problem with that approach: In documents with hundreds, or even thousands, of *small* images the `GlobalImageCache` as implemented becomes essentially pointless.

Hence this patch, where the `GlobalImageCache`-implementation is changed in the following ways:
 - We're still guaranteed to be able to cache a *minimum* number of images, set to `10` (similar as before).
 - If the *total* size of all the cached image data is below a threshold[2], we're allowed to cache additional images.

This patch thus *improve*, but doesn't completely fix, issue 12098. Note that that document is created by a *very poor* PDF generator, since every single page contains the *entire* document (with all of its /Resources) and to create the individual pages clipping is used.[3]

---
[1] Currently set to `10` images; imagine what would happen to overall memory usage if we encountered e.g. 50 images each 10 MB in size.

[2] This value was chosen, somewhat randomly, to be `40` megabytes; basically five times the [maximum individual image size per page](6249ef517d/src/display/api.js (L2483-L2484)).

[3] This surely has to be some kind of record w.r.t. how badly PDF generators can mess things up...
2021-01-26 12:00:12 +01:00
Calixte Denizet
539256c351 Add back dir property in spans in text layer
- aims to fix #12909
2021-01-26 12:00:05 +01:00
calixteman
a3f6882b06
JS -- add support for choice widget (#12826) 2021-01-25 23:40:57 +01:00
Calixte Denizet
52641e8643 Fix text layer regression tests in using the correct line-height property 2021-01-25 23:01:07 +01:00