We're already, since quite some time, using the standard Fullscreen API provided that it's available in the browser. The warning is only caused by the code that checks if the Fullscreen API is supported.
This patch uses a simple preprocessor tag to avoid the warning, since I'm assuming that in general, we want to try and remain backwards compatible with the prefixed versions of the Fullscreen API.
Fixes 7270.
When Firefox is run in e10s mode, which will soon be the default, the PDF.js zoom dropdown menu doesn't look right. This is apparently because the `<select>` DOM element is rendered in the parent, and that all the necessary style information isn't sent up from the child. See the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=910022.
Besides this causing the PDF.js UI to *look* worse in e10s, notably it also means that the `customScaleOption` isn't hidden like it ought to be.
To work-around that, this patch utilizes the `hidden` attribute, since https://bugzilla.mozilla.org/show_bug.cgi?id=1242450 at least made that work in e10s.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1194700.
Furthermore we introduce two new methods named `setCallback` and
`setReason` so external code does not change the properties of the class
directly. Finally we update various names of properties and methods to
be more self-explanatory.
With the recent PR 7172, which made the viewer modular, there's now a couple of modules that are no longer easily accessible (e.g. through the console).
This can make testing/debugging more difficult, and means that e.g. https://github.com/mozilla/pdf.js/wiki/Debugging-PDF.js#enabling no longer works in the generic viewer.
For now, as a simple solution, this patch just exposes those non-classes on `PDFViewerApplication` to ensure that they are available, and to avoid polluting the `window` scope.
Persist the state of content sidebar while browsing away from viewer and
initializing the same on returning back to the viewer. The state is saved
in persistent store preferences and used upon viewer initialization.
Fixes#6935
We cannot piggy-back on the `updateviewarea` event in order to update the stored sidebar state, since there're a number of cases where opening/switching the sidebar view won't fire a `updateviewarea` event.
Note that `updateviewarea` only fires when the position changes in the *viewer*, which means that it won't fire if e.g. the viewer is narrow, such that the sidebar overlays the document transparently; or when switching views, without the document position also changing.
This patch also moves the handling of `forceOpen` parameter in `PDFSidebar_switchView`, to prevent triggering back-to-back rendering and dispatching of events.
This is a regression from PR 7097.
(Also, out of scope for this PR, but I think that a `setTimeout` value of `1000 ms` is too large. Switching from scrolling to zooming can fell sluggish, and give the impression that nothing happens.)
[PDFThumbnailView] Re-factor the `canvas` to `image` conversion such that we always render to a `canvas`, and then replace it with an `image` once rendering is done
Functionality wise, `ensureThumbnailVisible` is essentially just a shorthand for `scrollThumbnailIntoView`. (And note that `PDFViewer` doesn't implement a `ensurePageVisible` method.)
The only remaining usage of `PDFThumbnailViewer_ensureThumbnailVisible` is inside `PDFPresentationMode`, which introduces an otherwise unnecessary `PDFThumbnailViewer` dependency there.
We're already relying on the `presentationmodechanged` event, in various files, to track the state of Presentation Mode. Thus we can simply listen for that event in `PDFSidebar` too, and update the thumbnails if necessary.
*This is a follow-up to PRs 6299 and 6441.*
The patch also adds an option to `PDFThumbnailView`, that disables the canvas-to-image conversion entirely, which might be useful in the context of issue 7026.
The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years.
To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years.
Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed).
This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
Changes `PDFOutlineView`/`PDFAttachmentView` to be initialized once, since we're always creating them, and refactor their `render` methods to instead pass in the `outline`/`attachments`.
For consistency with other "classes", the `PDFOutlineView`/`PDFAttachmentView` are renamed to `PDFOutlineViewer`/`PDFAttachmentViewer`.
Also, make sure that the outline/attachments are reset when the document is closed. Currently we keep the old ones around until the `getOutline`/`getAttachments` API calls are resolved for a new document.
To reduce code duplication, the initialization code now uses the `reset` method.
Also, this patch moves `charactersToNormalize` out of `PDFFindController`, since it seemed better suited to be a "constant".
Open http://www.puolustusvoimat.fi/wcm/61ba4180411e702ea19ee9e364705c96/luonnonmuonaohjelmalumo1985.pdf?MOD=AJPERES#pagemode=bookmarks.
Note how the outline looks entirely empty, but hovering over it you'll see that there are entries present. There's two separate issues here, first of all the fact that you cannot visually make out the outline items, and secondly that the lack of text means that the clickable area becomes too small.
In Adobe Reader this issue is somewhat mitigated, since they use an icon for every item. For PDF.js, the easist way to address this seems to be making use of a default title.
This issue should be *very* rare in practice, but given the simplicity of the solution I think that we should fix this.
The `hasImage` property is a left-over from older thumbnail code, and has been made obsolete by `renderingState`.
Having two different properties tracking (basically) the same state is asking for trouble, since it's very easy to forget to update one of them, with annoying bugs as the result.
