Since the zoom value should be in percent, using `PDFViewer.currentScale` will be wrong by a factor of 100, potentially causing the zoom level of the document to become wrong on load.
*This fixes a regression from PR 6192.*
Under some circumstances, the `resize` event handler in `viewer.js` is fired before the scale has been set. This can lead to PDF documents being rendered at the wrong zoom level when they are opened.
It seems that a way to reliably trigger this is to, using the Firefox addon, open a PDF file that triggers the `fallback` bar, in a new background tab (i.e. middle clicking on a link, or use the context menu).
Prior to PR 6192, we checked the selected option in the `scaleSelect` dropdown instead. Since `pageAutoOption` is selected by default in `viewer.html`, this should explain why the issue wasn't visible previously.
Fixes#6106
To avoid future regressions, two new unit tests were added:
1. A new PDF based on the report from #6106, which contains an
OpenAction of type JavaScript and a string "this.print({...}".
2. An existing PDF from https://bugzil.la/1001080 (from #4698).
Although it does not matter, since we don't execute the JavaScript code,
I have also changed "print(true)" to "print({})" since the print method
takes an object (not a boolean). See "Printing PDF documents", page 62:
http://adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_developer_guide.pdf
The special handling of the 'custom' scale value is only relevant for the `scaleSelect` dropdown in the standard viewer, hence I think that it should be placed in `viewer.js` instead.
After the creation of `PDFViewer`, its `_resetView` method takes care of resetting, among other things, the page number property. Hence we don't need to set `pdfViewer.currentPageNumber = 1;` here any more, and the comment is no longer accurate either.
*With this patch we're getting very close to fixing 6158.*
The only use-case for `PDFViewerApplication.updateScaleControls` is to try and avoid calling `selectScaleOption` from the `scalechange` event handler in viewer.js.
This will *only* happen when the user has manually changed the scale by using the `<select>` dropdown, which means that in reality this is just a micro optimization. Furthermore, `selectScaleOption` is only skipped for the "named" scale values (e.g. `auto`, `page-actual`, `page-fit`, `page-width`), thus further reducing the value of this code.
Also, since we're updating the scale `<select>` dropdown from an event handler, we're currently depending on the event being dispatched (and handled) completely before the next `scalechange` event. Relying on the execution order of the code in this way, even though it currently works, seems unfortunate since it *could* potentially cause the internal scale value and the UI from getting out of sync.
*This is the next step towards fixing 6158.*
This patch removes the dependency on the state of the scale `<select>` dropdown from the `resize` event handler, and instead uses the (in `PDFViewer`) stored `currentScaleValue`.
I believe that the way this code is currently written is purely for historical reasons, since originally *only* the numerical scale was stored internally (hence there was no other way to access the scale value).
However, since we now store the scale value, we should use it instead of quering the DOM. This helps ensure that the internally stored scale value is always accurately displayed in the UI (which should be good since, after the creation of `PDFViewer`, the `<select>` DOM element is now updated by an event handler).
*The next step towards fixing issue 6158.*
We can just as well access `pdfViewer.currentScaleValue` directly in `PDFViewerApplication`, instead of having a helper function which just acts as a wrapper for it.
This patch is the the first step towards to addressing issue 6158, which will be done by refactoring the code for setting/getting the current scale in `viewer.js`.
Before this patch, zooming in/out via the scroll wheel caused the page
to be zoomed relative to the upper-left corner of the page, i.e. the
upper-left corner of the page stays at a fixed position.
After this patch, the page is zoomed relative to the cursor position,
i.e. after zooming in/out, the part under the cursor 'has not moved'.
This only applies when the page does not fit in the viewport, because
pages smaller than the viewpoer are always centered.
The reason that this code can be moved is that the `if (this.loading && page === 1)` check, in the `pagechange` event handler in viewer.js, is never satisfied since `this.loading` is not defined in that scope.
This *could* be considered a regression from PR 5295, since prior to that `this.loading` was using the `PDFViewerApplication` scope (or `PDFView` as it were).
However, I don't think that we need to fix that since we've been shipping this code in no less than *three* Firefox releases (uplifted in https://bugzilla.mozilla.org/show_bug.cgi?id=1084158), without breaking the world.
An explanation of why the `pagechange` code works, despite `this.loading === undefined`, is that `set currentPageNumber` (in `PDFViewer`) returns early whenever `this.pdfDocument` isn't set. This check is, for all intents and purposes, functionally equivalent to checking `PDFViewerApplication.loading`.
Hence we can move the page switching code into `PDFViewer`, and also remove `PDFViewerApplication.loading` since it's not used any more.
(The `this.loading` property was added in PR 686, which was before the current viewer even existed.)
*Note:* The changes in this patch should also be beneficial to the viewer `components`, since requiring every implementer to provide their own `pagechange` event handler just to get `PDFViewer.currentPageNumber` to actually work seems like an unnecessary complication.
*This patch addresses an issue I stumbled upon while working on rewriting the history implementation.*
Currently the `updateviewarea` UI event doesn't include the `location`, and in the event handler in viewer.js we instead reach into `PDFViewer` to retrieve it. Not only does this seem conceptually wrong, it also makes the `updateviewarea` event less useful in general since it's currently only possible to access the `location` if you have a reference to the `PDFViewer`.
To me, this simply appears to be an oversight in the implementation, hence this patch which adds `location` to the `updateviewarea` event. It also changes `location` to be a "private" property of `PDFViewer`.
*This is a follow-up to PR 5966.*
Now that https://bugzilla.mozilla.org/show_bug.cgi?id=1151931 has landed, we're unfortunately in a situation where Firefox warns about `unreachable code after return statement` multiple times when using the PDF.js code in `node make server` mode.
I'm really sorry about the churn in this code!
However I don't think it's a good idea to let Firefox continue to printing these warnings in the console, since it increases the risk of missing actual errors.
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 uncomments a large portion of the Firefox specific code in viewer.js, by using a preprocessor "trick", to enable linting. Doing this actually uncovered some issues, e.g. variables defined multiple times.
- This patch also fixes a spelling error, `adobe pdfwritter` -> `abobe pdfwriter`, in the `KNOWN_GENERATORS` list used when reporting telemetry data in Firefox.
*Please note:* there's still some Firefox specific code that is commented out, but it's usually just one (or two) lines of code. Hence the risk that errors creep in should be much lower, compared to entire code-blocks.
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.
