Please see http://eslint.org/docs/rules/object-shorthand.
For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
Rather than having to manually use `initializedPromise`, which really ought to be a private property, to ensure that setting/getting values in the `ViewHistory` works as intended, this re-factoring simply changes all of its methods to be asynchronous.
Furthermore, a `getMultiple` method (mirroring the existing `setMultiple` one) is also added to `ViewHistory`.
Finally, this patch also addresses an existing issue, where certain preferences (e.g. the default zoom level) would be ignored when calling `setInitialView` if reading from the `ViewHistory` fails for some reason.
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.
The download method (and the PDF document properties) detect the
file name using `getPDFFileNameFromURL`. The title ought to also
display the PDF filename if available.
Ideally we'd remove the 'localized' event from the `eventBus`, but for backwards compatibility we keep it in `GENERIC` builds.
Note that while we want to ensure that the direction attribute of the HTML is updated as soon as the `localized` Promise is resolved, we purposely wait until the viewer has been initialized to ensure that the 'localized' event will always be dispatched.
With `bindEvents()` now being called after the viewer has been initialized, we no longer need to have `PDFViewerApplication.initialized` checks in the event handler functions.
Furthermore by moving the `window.addEventListener`s to a helper method, `PDFViewerApplication.initialized` checks are no longer necessary in the event handlers, hence we thus address part of issue 7797 here as well.
Note that in quick testing using `console.time/timeEnd`, both locally and with the Firefox addon, the total run time of the *entire* `PDFViewerApplication.initialize` function does not seem to change with this patch.
It seems that for normal web pages, at least in Firefox, the keyboard shortcuts <kbd>Ctrl</kbd> + <kbd>Up</kbd>/<kbd>Down</kbd> are functionally equivalent to <kbd>Home</kbd>/<kbd>End</kbd>. This is obviously an edge-case, but can be easily implemented by using the same logic as we do for <kbd>Home</kbd>/<kbd>End</kbd>.
Fixes 7852.
*Please note:* I'm finding it slightly difficult to interpret issue 7852, and bug 1285719, since among other things: the title includes the word "reverse" with no other mention of it, and the STR makes reference to print preview which doesn't seem applicable to the PDF viewer.
However, compared to regular web pages in Firefox, I think the behavior of this patch makes sense here.
This patch implements the page label functionality in a similar way as Adobe Reader.
For documents with page labels, if a non-existent page label is entered we'll try to fallback to the page number instead.
The patch also includes a preference (`disablePageLabels`), to make it easy to opt-out of using page labels if the user/implementor so wishes.
The way that `get/set currentPageLabel` is implemented in `PDFViewer`, is as wrappers for the corresponding `get/set currentPageNumber` functions, since that seemed like the cleanest solution.
The page labels are purposely *only* added to the page controls in the viewer UI, and not stored in e.g. the `ViewHistory`. Since doing so would mean adding unnecessary code complexity, without any real added value, and would also mean delaying the inital loading of PDF documents.
Note that this patch will ignore page labels if they are identical to standard page numbering, since in this case displaying the page labels adds no value (but only UI noise). The reason for handling this case specially, is that in practice a surprising number of PDF files include "pointless" page labels.
Note that in `FIREFOX/MOZCENTRAL/CHROME` builds of the standard viewer the `docBaseUrl` parameter will be set by default, since in that case it makes sense to use the current URL as a base.
For the `GENERIC` viewer, or the API itself, it doesn't make sense to try and set the `docBaseUrl` by default. However, custom deployments/implementations may still find the parameter useful.
When opening a PDF file that triggers the browser fallback bar in the Firefox addon/built-in version, e.g. http://web.archive.org/web/20110918100215/http://www.irs.gov/pub/irs-pdf/f1040.pdf (with forms *disabled*), and then reloading the document an error can be thrown.
The reason is that displaying the fallback bar triggers 'resize' events, and they can arrive *before* the viewer has had a chance to run all the necessary initialization code.
There's really no good reason to attempt to adjust the `max-height` of the `SecondaryToolbar` when it's not visible, so let's not do that anymore.
Also, we can listen for the `resize` event in `SecondaryToolbar`, to avoid having to manually call the `max-height` adjust function from various event handlers in `app.js`. Please note that by always adjusting the `max-height` when the toolbar is opened we no longer need the `localized` event, since it was mainly used to set a correct inital `max-height` value.
Please note that this is a hack, but I think that it should be OK for now to atleast get the preference landed. Refer to the code comment for further information.
Re: issue 7584 and PR 7586.
This patch is the first step towards implementing support for
interactive forms (AcroForms). It makes it possible to render text
widget annotations exactly like Adobe Reader/Acrobat.
Everything we implement for AcroForms is disabled by default using a
preference, mainly because it is not ready to use yet, but has to
implemented in many steps to avoid complexity. The preference allows us
to work with the code while not exposing the behavior by default. Mainly
storing entered values and printing them is still absent, which would be
minimal requirements for enabling this by default.
When clicking on the `pageNumber` input, or when using the keyboard shortcut <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>G</kbd>, the element isn't just focused but its contents is actually *selected* so that the user doesn't need to clear the input before entering a new `pageNumber`.
However, the `GoToPage` named action is only using `focus`, so let's change this to be consistent.
The following document can be used for testing: http://www2.informatik.uni-freiburg.de/~frank/ENG/beamer/example/Beamer-class-example1.pdf#zoom=page-fit
[screeenshot]
1. Expanding divs to improve text selection. (Yury)
2. Adding enhanceTextSelection as an option.
3. Moving feature functionality from text_layer_builder.js to text_layer.js.
4. Added expandTextDivs method to only load expanded divs on first click, and only show on subsequent clicks
In the `zoom{In, Out}` functions in `PDFViewerApplication`, we prevent the zoom value from becoming smaller/larger than `MIN_SCALE/MAX_SCALE`.
However, if the user sets the zoom level through the hash parameter the zoom buttons might not be correctly disabled; try http://mozilla.github.io/pdf.js/web/viewer.html#zoom=10.
Note that this issue has been present since "forever", but given that the solution is so simple I think that we should just fix this. (I'm also fixing a stupid typo I previously made in the JSDoc comment.)
There are PDF generators which create destinations with e.g. too large top values, which cause the wrong page to be scrolled into view because the offset becomes negative.
By ignoring negative offsets, we can prevent this issue, and get a similar behaviour as in Adobe Reader.
However, since we're also using `PDFViewer_scrollPageIntoView` in more cases than just when links (in the document/outline) are clicked, the patch adds a way to allow the caller to opt-out of this behaviour.
In e.g. the following situations, I think that we still want to be able to allow negative offsets: when restoring a position from the `ViewHistory`, when the `viewBookmark` button is used to obtain a link to the current position, or when maintaining the current position on zooming.
Rather than adding another parameter to `PDFViewer_scrollPageIntoView`, I've changed the signature to take an parameter object instead. To maintain backwards compatibility, I've added fallback code enclosed in a `GENERIC` preprocessor tag.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=874482.
With PR 7502 we no longer dispatch an event when the `val` is out of bounds, so to better communicate why nothing happens this patch logs an error in that case (similar to the logging of errors when trying to set an invalid scale).
The way that the default viewer is currently implemented, means that e.g. keyboard short-cuts could trigger the new error. Hence this patch also adds the necessary validation code, both to `app.js` and `pdf_link_service.js` to prevent unnecessary errors.
This patch attempts to cleanup a couple of things:
- Remove the `previousPageNumber` paramater. Prior to PR 7289, when the events were dispatched even when the active page didn't change, it made sense to be able to detect that in an event listener. However, now that's no longer the case, and furthermore other similar events (e.g. `scalechanging`/`scalechange`) don't include information about the previous state.
- Don't dispatch the events when the value passed to `set currentPageNumber` is out of bounds. Given that the active page doesn't change in this case, again similar to PR 7289, I don't think that the events should actually be dispatched in this case.
- Ensure that the value passed to `set currentPageNumber` is actually an integer, to avoid any issues (note how e.g. `set currentScale` has similar validation code).
Given that these changes could possibly affect the PDF.js `mochitest` integration tests in mozilla-central, in particular https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/test/browser_pdfjs_navigation.js, I ran the tests locally with this patch applied to ensure that they still pass.
