Note that these files were among the first to be converted to ES6 classes, so it probably makes sense to do another pass to bring them inline with the most recent ES6 conversions.
This patch contains the following improvements:
- Only fetch the various document properties *once* per PDF file opened, and cache the result (in a frozen object).
- Always update the *entire* dialog at once, to prevent inconsistent UI state (issue 8371).
- Ensure that the dialog, and all its internal properties, are reset when `PDFViewerApplication.close` is called.
- Inline, and re-factor, the `getProperties` method in `open`, since that's the only call-site.
- Always overwrite the fileSize with the value obtained from `pdfDocument.getDownloadInfo`, to ensure that it's correct.
- ES6-ify the code that's touched in this patch.
Fixes 8371.
In various viewer files, there's a number of cases where we basically duplicate the functionality of `createPromiseCapability` manually.
As far as I can tell, a couple of these cases have existed for a very long time, and notable even before the `createPromiseCapability` utility function existed.
Also, since we can write ES6 code now, the patch also replaces a couple of `bind` usages with arrow functions in code that's touched in the patch.
Note that as discussed on IRC, this makes the viewer slightly slower to load *only* in `gulp server` mode, however the difference seem slight enough that I think it will be fine.
Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
This patch:
- Simplifies the way fields are passed to the document properties overlay
- Simplifies the way fields are filled internally in the document properties overlay
- Avoids passing a document properties reference to the secondary toolbar
This patch:
- Puts public methods at the top of the file
- Puts private methods below the public methods and marks them with an underscore
- Adds JSDoc comments to the class
- Adds setDocumentAndUrl to avoid having to handle that in `viewer.js`
Since the link is no longer valid, we should remove it from the comment.
(Using the Internet Archive, it seems that the contents of that page was basically identical to the PDF specification.)
With the changes made in PR 5169 to enable quicker display of the File size, `setFileSize()` can now be called during file loading. This function parses *and* localizes the file size, where the l10n is a synchronous operation.
This patch:
* Re-factors `setFileSize()` to *only* update `rawFileSize`, and moves parsing and fetching of the l10n string to a separate method that isn't called until the Document Properties dialog is actually opened.
* Adds a couple of checks to make sure that `rawFileSize` is set to a positive number.
* Removes the `fileName` and `fileSize` properties. Since they are parsed every time the Document Properties dialog is opened, it doesn't seem necessary to cache them.
Currently the File size field in the Document Properties dialog isn't set until `PDFView.pdfDocument.getDownloadInfo()` is resolved. If the Document Properties dialog is opened while a PDF file is loading with range requests, this leads to the less desirable situation where all fields *except* File size are available.
In cases where `PDFView.open()` is called with the `args` parameter defined, and `args` contains the property `length`, we actually know the File size when the PDF file begins to load. (This is usually the case when ranged loading is used in the Firefox addon/built-in version.)
Hence we can use `args.length` to set the File size immediately when `PDFView.open()` is called, resulting in a better user experience.
Jonas Jenwald
Yury Delendik
Tim van der Meij
Manas
Collin Anderson
yscumc