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`
This patch:
- Passes in a reference to the current PDFThumbnailViewer, which is used to ensure that the current thumbnail becomes visible when exiting PresentationMode.
- Changes the way that the event listeners for the contextmenu items are defined, to avoid passing in a reference to the SecondaryToolbar.
- Ensures that |supportsFullscreen| always returns a boolean.
Currently `supportsFullscreen` will, when the browser supports the fullscreen API, return e.g. `function mozRequestFullScreen()` instead of `true`.
- Simplifies the |click| handler code when PresentationMode is active.
This code has been obsolete ever since PR 2919 landed.
- Removes hack used to workaround a bug in WebKit browsers, which caused |mousemove| events to be fired when the cursor changed.
This was fixed close to a year ago, see http://code.google.com/p/chromium/issues/detail?id=103041.
This patch:
- Adds a couple of utility methods to `PDFViewer` to enable checking `presentationModeState` without cumbersome comparisons.
- Disentangles `PresentationMode` from `PDFHistory` and `HandTool`, by adding event listeners for `presentationmodechanged` to both of them.
- Adds a utility function to `PDFViewerApplication` for requesting PresentationMode.
- Prevents initialization of `PresentationMode` if the browser does not support the fullscreen API.
After the refactoring in PR 5678, the B2G viewer now prints the following in the console:
```
ReferenceError: DownloadManager is not defined
```
This will obviously not matter once the B2G viewer is replaced with the new components-based one. But until that happens, I think it makes sense to just stub the class to suppress the error.
For consistency, this preference should be placed amongst the others. The current position is purely for "historical" reasons, since it was one of the first preferences that was added to the code.
In Blink-based browsers, there is a mismatch between document size and
paper size. Even if exactly the same values and unit are used, it is
possible that the printed results takes more pages than expected.
To solve the issue, the page size is set via @page size, and the canvas
and ancestor nodes are assigned a width+height of 100% (=relative to the
page). This change resolves bugs such as blank pages and split pages.
This patch also rearrange the order of the references to the DOM elements of the predefined zoom values, in viewer.js, to correspond with the element order in the current viewer UI. (The previous ordering is a leftover from the previous viewer UI.)
Instead of trying to hack around various browser defects, let's just disable PresentationMode in the affected browsers. This patch:
- Disables PresentationMode in IE11+ when the viewer is embedded; fixes 4711.
From reading IRC scrollback, it became clear that having to manually call `PDFFindController.resolveFirstPage` in order for the find functionality to work isn't particulary good. Hence this PR, which moves that code into `PDFViewer.setDocument` to make life easier for third-party implementations.
We can pass it in using the options object. Note that that this also avoids creating a DownloadManager object for each separate link (instead, having only one is enough).
Currently if you manage to e.g. open the console (with <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>K</kbd>) before the viewer is initialized, the following will be printed in the console: `TypeError: pdfViewer is null`.
This doesn't cause any actual errors, but nevertheless it seems like something we should avoid.
Followup to PR 5413.
Since `preferenceSidebarViewOnLoad` is an enumeration value, it seems better to initialize it with the default one instead of a boolean.
`preferencesPdfBugEnabled` uses a superfluous "s", which is a typo I made when I introduced it.
Currently when an exception is thrown, we try to reject `workerReadyCapability` with multiple arguments in src/core/api.js. This obviously doesn't work, hence this patch changes that to instead reject with the exception object as is.
In src/core/worker.js the exception is currently (unncessarily) wrapped in an object, so this patch also simplifies that to directly send the exception object instead.
As requested in #5178, this change debounces the scroll events.
The reason for doing so is that browsers can event-storm especially on
scroll, communicating hundreds of subpixel changes.
The main reason for this resulting in poor performance is that on each
scroll event `scrollTop` was queried, which forces layouting.
This change will use `requestAnimationFrame` to make sure the browser can
allocate enough time to other tasks. The delay is however quite small, thus
the reduction in executions is less noticeable. Modern browsers however utilize
`requestAnimationFrame` to smoothen out rendering.
Since the "Previous/Next Page" buttons are disabled when the first/last page is active, I think that for the sake of consistency the "Go to First/Last Page" should behave the same way.
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.
QtWebKit does not support file:-URLs in Web Workers.
To solve this issue, I'm loading file:-URLs in the main thread
for generic builds. file:-URLs load relatively quick, so there
is no need for sophisticated load progress notifications.
The absence of this property caused the following error in PDFView.download:
Cannot read property 'split' of undefined
This property was unset when the PDF was loaded through a typed array instead
of a URL. With the fix, the file name will default to "document.pdf", as
defined by getPDFFileNameFromURL in web/ui_utils.js
