Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e9bdbe4574
pdf.js/web/viewer.html

504 lines
27 KiB
HTML
Raw Normal View History

Add BOM to viewer.
2013-11-23 04:10:43 +09:00
<!DOCTYPE html>
Change to the Apache v2 license.
2012-09-01 07:48:21 +09:00
<!--
Copyright 2012 Mozilla Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Add note about adobe license.
2014-03-11 05:03:35 +09:00
Update Adobe CMaps URL and license They are now using Apache 2.0 as well.
2015-06-30 16:33:25 +09:00
Adobe CMap resources are covered by their own copyright but the same license:
Copyright 1990-2015 Adobe Systems Incorporated.
See https://github.com/adobe-type-tools/cmap-resources
Change to the Apache v2 license.
2012-09-01 07:48:21 +09:00
-->
Remove `moznomarginboxes`
2018-01-20 06:05:50 +09:00
<html dir="ltr" mozdisallowselectionprint>
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
<head>
Embed locale.properties in the viewer.html for extension
2012-05-01 11:55:21 +09:00
<meta charset="utf-8">
Add viewport metatag
2012-05-24 06:50:54 +09:00
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
Disable Google Translate on viewer in Chrome. test/pdfs/yo01.pdf triggered "This page is in Japanese. Would you like to translate it?" info bar in Chrome.
2013-07-16 07:13:05 +09:00
<!--#if GENERIC || CHROME-->
<meta name="google" content="notranslate">
<!--#endif-->
Merge branch 'master' into new-ui Conflicts: web/viewer.html web/viewer.js
2012-04-19 04:02:49 +09:00
<title>PDF.js viewer</title>
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
<!--#if MOZCENTRAL-->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#include viewer-snippet-firefox-extension.html-->
[CRX] Show nicely formatted URL in omnibox Before commit: chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf After commit: chrome-extension://EXTENSIONID/http://example/file.pdf Technical details: - The extension's background page uses the webRequest API to intercept requests for <extension host>/<real path to pdf>, and redirect it to the viewer's URL. - viewer.js uses history.replaceState to rewrite the URL, so that it's easier for users to recognize and copy-paste URLs. - The fake paths /http:, /https:, /file:, etc. have been added to the web_accessible_resources section of the manifest file, in order to avoid seeing chrome-extension://invalid/ instead of the actual URL when using history back/forward to navigate from/to the PDF viewer. - Since the relative path resolving doesn't work because relative URLs are inaccurate, a <base> tag has been added. This method has already been proven to work in the Firefox add-on. Notes: - This commit has been cherry-picked from crx-using-streams-api. - Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with a bug in Chrome <=30 - In Chrome, getting the contents of a FTP file is not possible, so there's no support for FTP files, even though the extension router recognizes the ftp: scheme.
2013-08-16 05:47:30 +09:00
<!--#endif-->
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-extension.html-->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
Remove XHTML leftovers from the viewer HTML files
2016-02-14 21:23:34 +09:00
<link rel="stylesheet" href="viewer.css">
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#if !PRODUCTION-->
Remove XHTML leftovers from the viewer HTML files
2016-02-14 21:23:34 +09:00
<link rel="resource" type="application/l10n" href="locale/locale.properties">
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
<!--#if !PRODUCTION-->
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-20 01:00:23 +09:00
<script defer src="../node_modules/es-module-shims/dist/es-module-shims.js"></script>
<script type="importmap-shim">
{
"imports": {
"pdfjs/": "../src/",
"pdfjs-lib": "../src/pdf.js",
[editor] Use the `fit-curve` package (issue 15004) Rather than including all of this external code in the PDF.js repository, we should be using the npm package instead. Unfortunately this is slightly more complicated than you'd hope, since the `fit-curve` package (which is older) isn't directly compatible with modern JavaScript modules. In particular, the following cases needed to be considered: - For the development viewer (i.e. `gulp server`) and the unit-tests, we thus need to build a fitCurve-bundle that can be directly `import`ed. - For the actual PDF.js build-targets, we can slightly reduce the sizes by depending on the "raw" `fit-curve` source-code. - For the Node.js unit-tests, the `fit-curve` package can be used as-is.
2022-07-07 06:02:53 +09:00
"pdfjs-web/": "./",
"pdfjs-fitCurve": "../build/dev-fitCurve/fit_curve.js"
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-20 01:00:23 +09:00
}
}
</script>
<script src="viewer.js" type="module-shim"></script>
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#if (GENERIC && !MINIFIED) -->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#include viewer-snippet.html-->
<!--#endif-->
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#if !MINIFIED -->
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-20 01:00:23 +09:00
<!--<script src="viewer.js"></script>-->
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#else-->
<!--#include viewer-snippet-minified.html-->
<!--#endif-->
pr #3356 squashing commits.
2013-06-19 01:05:55 +09:00
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</head>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Let the loadingBar have the same width as the viewerContainer For years the loadingBar and sidebarContainer has had a slightly annoying and unfortunate dependency, since the loadingBar width follows the main toolbar width[1]. To prevent the loadingBar from obscuring part of the sidebarContainer, especially the buttons, the sidebarContainer is thus moved down when the loadingBar is visible. This has always annoyed me[2], since it means that the buttons in the sidebar may thus move vertically which seems bad from a UX perspective. Now that CSS variables are available in all supported browsers[3] however, fixing the loadingBar/sidebarContainer overlap issues are finally easy. The solution is simply to let the sidebarContainer, when visible, control the loadingBar left position (right in RTL locales) in the same way that the viewerContainer is handled. Hence the sidebarContainer can now have a *consistent* vertical postition, without the loadingBar overlapping it. --- [1] Obviously the right position (left in RTL locales) of the loadingBar is, potentially, reduced to account for a scrollbar. [2] I've tried to fix this a few times, but it always seemed like more trouble than it's worth. [3] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Browser_compatibility
2020-09-08 21:13:10 +09:00
<body tabindex="1">
Small refactoring of the loadingBar hiding code
2014-08-17 07:22:05 +09:00
<div id="outerContainer">
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
Move sidebar open class.
2012-04-26 05:46:17 +09:00
<div id="sidebarContainer">
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
<div id="toolbarSidebar">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 20:57:43 +09:00
<div id="toolbarSidebarLeft">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="sidebarViewButtons" class="splitToolbarButton toggled" role="radiogroup">
<button id="viewThumbnail" class="toolbarButton toggled" title="Show Thumbnails" tabindex="2" data-l10n-id="thumbs" role="radio" aria-checked="true" aria-controls="thumbnailView">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 20:57:43 +09:00
<span data-l10n-id="thumbs_label">Thumbnails</span>
</button>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<button id="viewOutline" class="toolbarButton" title="Show Document Outline (double-click to expand/collapse all items)" tabindex="3" data-l10n-id="document_outline" role="radio" aria-checked="false" aria-controls="outlineView">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 20:57:43 +09:00
<span data-l10n-id="document_outline_label">Document Outline</span>
</button>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<button id="viewAttachments" class="toolbarButton" title="Show Attachments" tabindex="4" data-l10n-id="attachments" role="radio" aria-checked="false" aria-controls="attachmentsView">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 20:57:43 +09:00
<span data-l10n-id="attachments_label">Attachments</span>
</button>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<button id="viewLayers" class="toolbarButton" title="Show Layers (double-click to reset all layers to the default state)" tabindex="5" data-l10n-id="layers" role="radio" aria-checked="false" aria-controls="layersView">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 20:57:43 +09:00
<span data-l10n-id="layers_label">Layers</span>
</button>
</div>
</div>
<div id="toolbarSidebarRight">
<div id="outlineOptionsContainer" class="hidden">
<div class="verticalToolbarSeparator"></div>
<button id="currentOutlineItem" class="toolbarButton" disabled="disabled" title="Find Current Outline Item" tabindex="6" data-l10n-id="current_outline_item">
<span data-l10n-id="current_outline_item_label">Current Outline Item</span>
</button>
</div>
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
</div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="sidebarContent">
<div id="thumbnailView">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="outlineView" class="hidden">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</div>
Preliminary attachments support Added a partial Filespec support Added getAttachments in API Added a new attachments view in UI (with a new icon by @shorlander)
2014-03-19 05:32:47 +09:00
<div id="attachmentsView" class="hidden">
</div>
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-07 04:01:03 +09:00
<div id="layersView" class="hidden">
</div>
Switching to the document outline view if the document structure is present
2011-08-22 11:05:10 +09:00
</div>
Remove CSS variables feature-testing from `PDFSidebarResizer` CSS variables are now supported in all reasonably modern browsers, according to: - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Browser_compatibility - https://caniuse.com/css-variables
2020-09-09 20:29:44 +09:00
<div id="sidebarResizer"></div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div> <!-- sidebarContainer -->
<div id="mainContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="findbar hidden doorHanger" id="findbar">
<div id="findbarInputContainer">
[GENERIC viewer] Try to improve a11y, for search results, in the findbar (issue 14525) Note that it seemed necessary to re-factor the `findResultsCount` and `findMsg` element grouping, in the HTML/CSS code, in order those elements to be correctly announced by a11y software in Firefox. The following MDN articles may be helpful here: - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live
2022-04-01 06:12:56 +09:00
<input id="findInput" class="toolbarField" title="Find" placeholder="Find in document…" tabindex="91" data-l10n-id="find_input" aria-invalid="false">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton">
[GENERIC viewer] Simplify the styling of the previous/next findbar buttons The styling of the previous/next-buttons and the findInput, with the elements being "glued" together, was supposed to mimic the styling used in the Firefox *browser* findbar. However, after the most recent re-styling of the Firefox browser UI these elements are now visually separated. Hence it makes sense, as far as I'm concerned, to try and follow this styling for the findbar used in the GENERIC viewer. One benefit of doing this is that we get more consistent styling, since the buttons now look/behave identically in both the main toolbar and the findbar. Additionally this also simplifies the CSS a bit, since a lot of the existing findbar-specific rules can be removed.
2022-04-19 20:43:24 +09:00
<button id="findPrevious" class="toolbarButton" title="Find the previous occurrence of the phrase" tabindex="92" data-l10n-id="find_previous">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span data-l10n-id="find_previous_label">Previous</span>
</button>
<div class="splitToolbarButtonSeparator"></div>
[GENERIC viewer] Simplify the styling of the previous/next findbar buttons The styling of the previous/next-buttons and the findInput, with the elements being "glued" together, was supposed to mimic the styling used in the Firefox *browser* findbar. However, after the most recent re-styling of the Firefox browser UI these elements are now visually separated. Hence it makes sense, as far as I'm concerned, to try and follow this styling for the findbar used in the GENERIC viewer. One benefit of doing this is that we get more consistent styling, since the buttons now look/behave identically in both the main toolbar and the findbar. Additionally this also simplifies the CSS a bit, since a lot of the existing findbar-specific rules can be removed.
2022-04-19 20:43:24 +09:00
<button id="findNext" class="toolbarButton" title="Find the next occurrence of the phrase" tabindex="93" data-l10n-id="find_next">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span data-l10n-id="find_next_label">Next</span>
</button>
</div>
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsOneContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<input type="checkbox" id="findHighlightAll" class="toolbarField" tabindex="94">
[GENERIC viewer] Use consistent casing, for the labels, in the findbar Note that the *browser* findbar in Firefox uses "Title Case" for the labels, and it thus seem like a good idea to ensure that `PDFFindBar` in consistent with that. Furthermore, the new label added in PR #13261 uses the "Title Case" format which means that currently the default viewer findbar looks inconsistent. *Please note:* Based on the official Firefox localization docs, see https://firefox-source-docs.mozilla.org/l10n/overview.html#string-updates, changing only the casing should *not* require updating the key: > 1) If the change is minor, like fixing a spelling error or case, the developer should update the en-US translation without changing the l10n-id.
2022-02-05 19:10:53 +09:00
<label for="findHighlightAll" class="toolbarLabel" data-l10n-id="find_highlight">Highlight All</label>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<input type="checkbox" id="findMatchCase" class="toolbarField" tabindex="95">
[GENERIC viewer] Use consistent casing, for the labels, in the findbar Note that the *browser* findbar in Firefox uses "Title Case" for the labels, and it thus seem like a good idea to ensure that `PDFFindBar` in consistent with that. Furthermore, the new label added in PR #13261 uses the "Title Case" format which means that currently the default viewer findbar looks inconsistent. *Please note:* Based on the official Firefox localization docs, see https://firefox-source-docs.mozilla.org/l10n/overview.html#string-updates, changing only the casing should *not* require updating the key: > 1) If the change is minor, like fixing a spelling error or case, the developer should update the en-US translation without changing the l10n-id.
2022-02-05 19:10:53 +09:00
<label for="findMatchCase" class="toolbarLabel" data-l10n-id="find_match_case_label">Match Case</label>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsTwoContainer">
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
<input type="checkbox" id="findMatchDiacritics" class="toolbarField" tabindex="96">
<label for="findMatchDiacritics" class="toolbarLabel" data-l10n-id="find_match_diacritics_label">Match Diacritics</label>
<input type="checkbox" id="findEntireWord" class="toolbarField" tabindex="97">
[GENERIC viewer] Use consistent casing, for the labels, in the findbar Note that the *browser* findbar in Firefox uses "Title Case" for the labels, and it thus seem like a good idea to ensure that `PDFFindBar` in consistent with that. Furthermore, the new label added in PR #13261 uses the "Title Case" format which means that currently the default viewer findbar looks inconsistent. *Please note:* Based on the official Firefox localization docs, see https://firefox-source-docs.mozilla.org/l10n/overview.html#string-updates, changing only the casing should *not* require updating the key: > 1) If the change is minor, like fixing a spelling error or case, the developer should update the en-US translation without changing the l10n-id.
2022-02-05 19:10:53 +09:00
<label for="findEntireWord" class="toolbarLabel" data-l10n-id="find_entire_word_label">Whole Words</label>
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
</div>
[GENERIC viewer] Try to improve a11y, for search results, in the findbar (issue 14525) Note that it seemed necessary to re-factor the `findResultsCount` and `findMsg` element grouping, in the HTML/CSS code, in order those elements to be correctly announced by a11y software in Firefox. The following MDN articles may be helpful here: - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live
2022-04-01 06:12:56 +09:00
<div id="findbarMessageContainer" aria-live="polite">
Simplify the `findResultsCount` span toggling, by using the same approach as with the `findMsg` span
2022-02-04 06:16:56 +09:00
<span id="findResultsCount" class="toolbarLabel"></span>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span id="findMsg" class="toolbarLabel"></span>
Add pilot find next/prev icons; localization
2012-10-06 09:15:06 +09:00
</div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div> <!-- findbar -->
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
<div class="editorParamsToolbar hidden doorHangerRight" id="editorFreeTextParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
[Editor] Simplify the strings for the tools in the UI
2022-07-24 23:35:44 +09:00
<label for="editorFreeTextColor" class="editorParamsLabel" data-l10n-id="editor_free_text_color">Color</label>
[editor] Remove the unused `name`-property from the editorParamsToolbars DOM elements As far as I can tell, this is completely unused and can thus be removed.
2022-06-29 18:13:23 +09:00
<input type="color" id="editorFreeTextColor" class="editorParamsColor" tabindex="100">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
<div class="editorParamsSetter">
[Editor] Simplify the strings for the tools in the UI
2022-07-24 23:35:44 +09:00
<label for="editorFreeTextFontSize" class="editorParamsLabel" data-l10n-id="editor_free_text_size">Size</label>
[editor] Remove the unused `name`-property from the editorParamsToolbars DOM elements As far as I can tell, this is completely unused and can thus be removed.
2022-06-29 18:13:23 +09:00
<input type="range" id="editorFreeTextFontSize" class="editorParamsSlider" value="10" min="5" max="100" step="1" tabindex="101">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
</div>
</div>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorInkParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
[Editor] Simplify the strings for the tools in the UI
2022-07-24 23:35:44 +09:00
<label for="editorInkColor" class="editorParamsLabel" data-l10n-id="editor_ink_color">Color</label>
[editor] Remove the unused `name`-property from the editorParamsToolbars DOM elements As far as I can tell, this is completely unused and can thus be removed.
2022-06-29 18:13:23 +09:00
<input type="color" id="editorInkColor" class="editorParamsColor" tabindex="102">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
<div class="editorParamsSetter">
[Editor] Simplify the strings for the tools in the UI
2022-07-24 23:35:44 +09:00
<label for="editorInkThickness" class="editorParamsLabel" data-l10n-id="editor_ink_thickness">Thickness</label>
[editor] Remove the unused `name`-property from the editorParamsToolbars DOM elements As far as I can tell, this is completely unused and can thus be removed.
2022-06-29 18:13:23 +09:00
<input type="range" id="editorInkThickness" class="editorParamsSlider" value="1" min="1" max="20" step="1" tabindex="103">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
[Editor] Add the possibility to change line opacity in Ink editor
2022-07-25 05:19:09 +09:00
<div class="editorParamsSetter">
[Editor] Simplify the strings for the tools in the UI
2022-07-24 23:35:44 +09:00
<label for="editorInkOpacity" class="editorParamsLabel" data-l10n-id="editor_ink_opacity">Opacity</label>
[Editor] Add the possibility to change line opacity in Ink editor
2022-07-25 05:19:09 +09:00
<input type="range" id="editorInkOpacity" class="editorParamsSlider" value="100" min="1" max="100" step="1" tabindex="104">
</div>
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
</div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div id="secondaryToolbar" class="secondaryToolbar hidden doorHangerRight">
<div id="secondaryToolbarButtonContainer">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="secondaryPresentationMode" class="secondaryToolbarButton visibleLargeView" title="Switch to Presentation Mode" tabindex="51" data-l10n-id="presentation_mode">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="presentation_mode_label">Presentation Mode</span>
</button>
Stop bundling the openFile-buttons in the CHROME build This is, for all intents and purposes, equivalent to PR 14833 and slightly reduces the size of the `gulp chromium` output.
2022-05-08 05:05:39 +09:00
<!--#if GENERIC-->
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="secondaryOpenFile" class="secondaryToolbarButton visibleLargeView" title="Open File" tabindex="52" data-l10n-id="open_file">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="open_file_label">Open</span>
</button>
Stop bundling the openFile-buttons in the MOZCENTRAL build Note how both of the openFile-buttons are always hidden during viewer initialization in the MOZCENTRAL build, i.e. the *built-in* Firefox PDF Viewer. Despite that we still include HTML, CSS, and JavaScript code for these buttons in the build. This patch *reduces* the size of the `gulp mozcentral` output by `1679` bytes, which isn't a lot but still cannot hurt.
2022-04-25 17:06:47 +09:00
<!--#endif-->
Secondary toolbar
2013-09-05 06:48:31 +09:00
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="secondaryPrint" class="secondaryToolbarButton visibleMediumView" title="Print" tabindex="53" data-l10n-id="print">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="print_label">Print</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="secondaryDownload" class="secondaryToolbarButton visibleMediumView" title="Download" tabindex="54" data-l10n-id="download">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="download_label">Download</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<a href="#" id="secondaryViewBookmark" class="secondaryToolbarButton visibleSmallView" title="Current view (copy or open in new window)" tabindex="55" data-l10n-id="bookmark">
Add the viewBookmark button to the secondary toolbar
2013-09-27 18:44:45 +09:00
<span data-l10n-id="bookmark_label">Current View</span>
</a>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div class="horizontalToolbarSeparator visibleLargeView"></div>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="firstPage" class="secondaryToolbarButton" title="Go to First Page" tabindex="56" data-l10n-id="first_page">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="first_page_label">Go to First Page</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="lastPage" class="secondaryToolbarButton" title="Go to Last Page" tabindex="57" data-l10n-id="last_page">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="last_page_label">Go to Last Page</span>
</button>
<div class="horizontalToolbarSeparator"></div>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="pageRotateCw" class="secondaryToolbarButton" title="Rotate Clockwise" tabindex="58" data-l10n-id="page_rotate_cw">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="page_rotate_cw_label">Rotate Clockwise</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="pageRotateCcw" class="secondaryToolbarButton" title="Rotate Counterclockwise" tabindex="59" data-l10n-id="page_rotate_ccw">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="page_rotate_ccw_label">Rotate Counterclockwise</span>
</button>
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
<div class="horizontalToolbarSeparator"></div>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="cursorToolButtons" role="radiogroup">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="cursorSelectTool" class="secondaryToolbarButton toggled" title="Enable Text Selection Tool" tabindex="60" data-l10n-id="cursor_text_select_tool" role="radio" aria-checked="true">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="cursor_text_select_tool_label">Text Selection Tool</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="cursorHandTool" class="secondaryToolbarButton" title="Enable Hand Tool" tabindex="61" data-l10n-id="cursor_hand_tool" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="cursor_hand_tool_label">Hand Tool</span>
</button>
</div>
cleaned whitespace
2015-02-03 00:12:52 +09:00
Document properties
2014-01-22 08:07:07 +09:00
<div class="horizontalToolbarSeparator"></div>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="scrollModeButtons" role="radiogroup">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="scrollPage" class="secondaryToolbarButton" title="Use Page Scrolling" tabindex="62" data-l10n-id="scroll_page" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="scroll_page_label">Page Scrolling</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="scrollVertical" class="secondaryToolbarButton toggled" title="Use Vertical Scrolling" tabindex="63" data-l10n-id="scroll_vertical" role="radio" aria-checked="true">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="scroll_vertical_label" >Vertical Scrolling</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="scrollHorizontal" class="secondaryToolbarButton" title="Use Horizontal Scrolling" tabindex="64" data-l10n-id="scroll_horizontal" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="scroll_horizontal_label">Horizontal Scrolling</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="scrollWrapped" class="secondaryToolbarButton" title="Use Wrapped Scrolling" tabindex="65" data-l10n-id="scroll_wrapped" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="scroll_wrapped_label">Wrapped Scrolling</span>
</button>
</div>
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
Remove the `PDFSinglePageViewer`-specific code from `web/secondary_toolbar.js` (PR 9877 follow-up) This was added on the assumption that the viewer would (eventually) start using the `PDFSinglePageViewer` for e.g. PAGE-scrolling mode and PresentationMode. However, having both a `PDFViewer` and a `PDFSinglePageViewer` side-by-side in the viewer would've been tricky to implement well, which is why PR 14112 implemented PAGE-scrolling for the general `BaseViewer` instead. Given that the default viewer is no longer (potentially) going to use `PDFSinglePageViewer`, there's code in the `SecondaryToolbar` (and related CSS rules) which is now unnecessary.
2021-11-29 02:36:25 +09:00
<div class="horizontalToolbarSeparator"></div>
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="spreadModeButtons" role="radiogroup">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="spreadNone" class="secondaryToolbarButton toggled" title="Do not join page spreads" tabindex="66" data-l10n-id="spread_none" role="radio" aria-checked="true">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="spread_none_label">No Spreads</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="spreadOdd" class="secondaryToolbarButton" title="Join page spreads starting with odd-numbered pages" tabindex="67" data-l10n-id="spread_odd" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="spread_odd_label">Odd Spreads</span>
</button>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="spreadEven" class="secondaryToolbarButton" title="Join page spreads starting with even-numbered pages" tabindex="68" data-l10n-id="spread_even" role="radio" aria-checked="false">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<span data-l10n-id="spread_even_label">Even Spreads</span>
</button>
</div>
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
Remove the `PDFSinglePageViewer`-specific code from `web/secondary_toolbar.js` (PR 9877 follow-up) This was added on the assumption that the viewer would (eventually) start using the `PDFSinglePageViewer` for e.g. PAGE-scrolling mode and PresentationMode. However, having both a `PDFViewer` and a `PDFSinglePageViewer` side-by-side in the viewer would've been tricky to implement well, which is why PR 14112 implemented PAGE-scrolling for the general `BaseViewer` instead. Given that the default viewer is no longer (potentially) going to use `PDFSinglePageViewer`, there's code in the `SecondaryToolbar` (and related CSS rules) which is now unnecessary.
2021-11-29 02:36:25 +09:00
<div class="horizontalToolbarSeparator"></div>
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="documentProperties" class="secondaryToolbarButton" title="Document Properties…" tabindex="69" data-l10n-id="document_properties" aria-controls="documentPropertiesDialog">
Miscellaneous improvements for the document properties dialog
2014-01-23 08:30:48 +09:00
<span data-l10n-id="document_properties_label">Document Properties…</span>
Document properties
2014-01-22 08:07:07 +09:00
</button>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div>
</div> <!-- secondaryToolbar -->
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbar">
<div id="toolbarContainer">
<div id="toolbarViewer">
<div id="toolbarViewerLeft">
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and aria-controls state In testing, screen readers such as JAWS have trouble understanding the expanded state of the buttons that expand hidden menus due to lacking aria-expanded attribute. Also, given that the buttons do not contain the controlled/shown element, they should also define the aria-controls attribute with associated element id per https://www.w3.org/TR/wai-aria-1.1/#aria-expanded This fixes adds these requirements for the sidebar, find, and secondary toolbar buttons.
2021-02-02 07:16:20 +09:00
<button id="sidebarToggle" class="toolbarButton" title="Toggle Sidebar" tabindex="11" data-l10n-id="toggle_sidebar" aria-expanded="false" aria-controls="sidebarContainer">
Bug #767698 Slider Rename Bug #767698 Slider Rename
2013-01-31 22:14:48 +09:00
<span data-l10n-id="toggle_sidebar_label">Toggle Sidebar</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbarButtonSpacer"></div>
fix(a11y): resolve sidebar, find, toolbar missing aria-expanded and aria-controls state In testing, screen readers such as JAWS have trouble understanding the expanded state of the buttons that expand hidden menus due to lacking aria-expanded attribute. Also, given that the buttons do not contain the controlled/shown element, they should also define the aria-controls attribute with associated element id per https://www.w3.org/TR/wai-aria-1.1/#aria-expanded This fixes adds these requirements for the sidebar, find, and secondary toolbar buttons.
2021-02-02 07:16:20 +09:00
<button id="viewFind" class="toolbarButton" title="Find in Document" tabindex="12" data-l10n-id="findbar" aria-expanded="false" aria-controls="findbar">
Add (and adjust) a couple of findbar `title` attributes, in `viewer.html`, that doesn't agree with the `l10n/en-US/viewer.properties` file The point of this patch is to fix a couple of inconsistencies in `viewer.html`, compared to the locale files, such that the viewer would work correctly even without the `l10n/` files present. *Note:* Since this isn't changing any of the locale files, we should *not* need to update any of the string names. Looking through the history of the findbar code, it seems that the `findPrevious`/`findNext` buttons have never had a `title` set (note PR 2168, which was the initial findbar implementation). Furthermore, the `placeholder` of the `findInput` didn't agree 100% with locale file either, so this is also adjusted.
2017-03-12 17:42:20 +09:00
<span data-l10n-id="findbar_label">Find</span>
Add some door hanger styling for the find bar
2012-09-29 04:30:07 +09:00
</button>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton hiddenSmallView">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button class="toolbarButton" title="Previous Page" id="previous" tabindex="13" data-l10n-id="previous">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="previous_label">Previous</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="splitToolbarButtonSeparator"></div>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button class="toolbarButton" title="Next Page" id="next" tabindex="14" data-l10n-id="next">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="next_label">Next</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<input type="number" id="pageNumber" class="toolbarField" title="Page" value="1" size="4" min="1" tabindex="15" data-l10n-id="page" autocomplete="off">
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<span id="numPages" class="toolbarLabel"></span>
</div>
<div id="toolbarViewerRight">
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<button id="presentationMode" class="toolbarButton hiddenLargeView" title="Switch to Presentation Mode" tabindex="31" data-l10n-id="presentation_mode">
Renames fullscreen to presentation mode
2012-09-21 23:35:18 +09:00
<span data-l10n-id="presentation_mode_label">Presentation Mode</span>
Correct l10n and address yury's comments
2012-07-31 00:58:34 +09:00
</button>
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
Stop bundling the openFile-buttons in the CHROME build This is, for all intents and purposes, equivalent to PR 14833 and slightly reduces the size of the `gulp chromium` output.
2022-05-08 05:05:39 +09:00
<!--#if GENERIC-->
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<button id="openFile" class="toolbarButton hiddenLargeView" title="Open File" tabindex="32" data-l10n-id="open_file">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="open_file_label">Open</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Stop bundling the openFile-buttons in the MOZCENTRAL build Note how both of the openFile-buttons are always hidden during viewer initialization in the MOZCENTRAL build, i.e. the *built-in* Firefox PDF Viewer. Despite that we still include HTML, CSS, and JavaScript code for these buttons in the build. This patch *reduces* the size of the `gulp mozcentral` output by `1679` bytes, which isn't a lot but still cannot hurt.
2022-04-25 17:06:47 +09:00
<!--#endif-->
Fixes tab order and focus highlight
2012-05-02 01:43:48 +09:00
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<button id="print" class="toolbarButton hiddenMediumView" title="Print" tabindex="33" data-l10n-id="print">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="print_label">Print</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<button id="download" class="toolbarButton hiddenMediumView" title="Download" tabindex="34" data-l10n-id="download">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="download_label">Download</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<a href="#" id="viewBookmark" class="toolbarButton hiddenSmallView" title="Current view (copy or open in new window)" tabindex="35" data-l10n-id="bookmark">
Add the viewBookmark button to the secondary toolbar
2013-09-27 18:44:45 +09:00
<span data-l10n-id="bookmark_label">Current View</span>
</a>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div class="verticalToolbarSeparator hiddenSmallView"></div>
cleaned whitespace
2015-02-03 00:12:52 +09:00
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<div id="editorModeButtons" class="splitToolbarButton toggled hidden" role="radiogroup">
[editor] Remove the `editorNone` toolbar button (bug 1787295)
2022-08-26 06:18:02 +09:00
<button id="editorFreeText" class="toolbarButton" disabled="disabled" title="Add FreeText Annotation" role="radio" aria-checked="false" tabindex="36" data-l10n-id="editor_free_text">
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<span data-l10n-id="editor_free_text_label">FreeText Annotation</span>
</button>
[editor] Remove the `editorNone` toolbar button (bug 1787295)
2022-08-26 06:18:02 +09:00
<button id="editorInk" class="toolbarButton" disabled="disabled" title="Add Ink Annotation" role="radio" aria-checked="false" tabindex="37" data-l10n-id="editor_ink">
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-21 01:08:41 +09:00
<span data-l10n-id="editor_ink_label">Ink Annotation</span>
</button>
</div>
<!-- Should be visible when the "editorModeButtons" are visible. -->
<div id="editorModeSeparator" class="verticalToolbarSeparator hidden"></div>
[edition] Add a FreeText editor (#14970) - add a basic UI to edit some text in a pdf; - an editor can be moved, suppressed, cut, copied, pasted, selected; - add an undo/redo manager.
2022-06-01 17:38:08 +09:00
<button id="secondaryToolbarToggle" class="toolbarButton" title="Tools" tabindex="48" data-l10n-id="tools" aria-expanded="false" aria-controls="secondaryToolbar">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="tools_label">Tools</span>
cleaned whitespace
2015-02-03 00:12:52 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<div id="toolbarViewerMiddle">
<div class="splitToolbarButton">
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="zoomOut" class="toolbarButton" title="Zoom Out" tabindex="21" data-l10n-id="zoom_out">
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<span data-l10n-id="zoom_out_label">Zoom Out</span>
</button>
<div class="splitToolbarButtonSeparator"></div>
Remove redundant class names from the button DOM-elements Note how in the `viewer.html` file we're specifying class names for most buttons, despite that not really being necessary. First of all, in many cases those class names are *identical* to the element-ids. Secondly, looking through the CSS rules they are only ever used when specifying button icons. All-in-all, we should be able to simplify the HTML-code and use the element-ids in the CSS rules instead. Obviously ids have a higher CSS specificity than classes, but given how the old classes were being used that shouldn't be a problem here. Also, the patch generalizes the styling for buttons (e.g. `viewBookmark`) that are *actually* link-elements. Finally, while slightly unrelated, this patch also removes a little bit of duplication when specifying the border for `toolbarField`s.
2022-04-27 23:04:00 +09:00
<button id="zoomIn" class="toolbarButton" title="Zoom In" tabindex="22" data-l10n-id="zoom_in">
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<span data-l10n-id="zoom_in_label">Zoom In</span>
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<span id="scaleSelectContainer" class="dropdownToolbarButton">
<select id="scaleSelect" title="Zoom" tabindex="23" data-l10n-id="zoom">
<option id="pageAutoOption" title="" value="auto" selected="selected" data-l10n-id="page_scale_auto">Automatic Zoom</option>
<option id="pageActualOption" title="" value="page-actual" data-l10n-id="page_scale_actual">Actual Size</option>
update inconsistent names
2017-07-11 04:27:39 +09:00
<option id="pageFitOption" title="" value="page-fit" data-l10n-id="page_scale_fit">Page Fit</option>
<option id="pageWidthOption" title="" value="page-width" data-l10n-id="page_scale_width">Page Width</option>
Make the `customScaleOption` disabled to prevent it being keyboard accessible (bug 1315608) Given that the `customScaleOption` should already be hidden, provided that the browser supports that, this patch also prevents it from being accessible via the keyboard. As far as my testing goes in various browsers, this doesn't seem to have any ill effects, and note that we're already explicitly ignoring the `custom` value in the `select` event handler. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1315608.
2016-11-08 20:04:55 +09:00
<option id="customScaleOption" title="" value="custom" disabled="disabled" hidden="true"></option>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<option title="" value="0.5" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 50 }'>50%</option>
<option title="" value="0.75" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 75 }'>75%</option>
<option title="" value="1" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 100 }'>100%</option>
<option title="" value="1.25" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 125 }'>125%</option>
<option title="" value="1.5" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 150 }'>150%</option>
<option title="" value="2" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 200 }'>200%</option>
<option title="" value="3" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 300 }'>300%</option>
<option title="" value="4" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 400 }'>400%</option>
</select>
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
</div>
Implement progressive loading of PDFs
2013-02-07 08:19:29 +09:00
<div id="loadingBar">
<div class="progress">
<div class="glimmer">
</div>
</div>
</div>
Simple search results
2011-12-12 10:38:20 +09:00
</div>
</div>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Allow scrolling by keyboard in Chrome/Opera Set "tabindex" attribute to allow focus; Added "outline: none" to prevent focus ring from appearing. Fixes #3443
2013-07-06 22:37:03 +09:00
<div id="viewerContainer" tabindex="0">
Move text_layer_builder and pdf_viewer styles out
2014-10-01 00:48:29 +09:00
<div id="viewer" class="pdfViewer"></div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
Stop including the "errorWrapper" HTML code in `MOZCENTRAL`-builds Given that these HTML elements are not being used at all in `MOZCENTRAL`-builds, note the preprocessor check in `PDFViewerApplication._otherError`, we obviously don't need the HTML code either.
2021-02-14 18:39:34 +09:00
<!--#if !MOZCENTRAL-->
Fix the error box.
2012-04-26 09:20:13 +09:00
<div id="errorWrapper" hidden='true'>
<div id="errorMessageLeft">
<span id="errorMessage"></span>
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorShowMore" data-l10n-id="error_more_info">
Fix the error box.
2012-04-26 09:20:13 +09:00
More Information
</button>
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorShowLess" data-l10n-id="error_less_info" hidden='true'>
Fix the error box.
2012-04-26 09:20:13 +09:00
Less Information
</button>
</div>
<div id="errorMessageRight">
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorClose" data-l10n-id="error_close">
Fix the error box.
2012-04-26 09:20:13 +09:00
Close
</button>
</div>
Stop bundling `errorWrapper` CSS rules in the MOZCENTRAL build Note that both the `errorWrapper` HTML and JavaScript code is being ignored in the MOZCENTRAL build, i.e. the *built-in* Firefox PDF Viewer, however the CSS rules are still being included. That seems totally unnecessary, and while we currently don't have full build-target support in the CSS pre-processor we can actually improve things quite easily anyway. By (ab)using the existing CSS pre-processor, which will remove any non-Firefox CSS rules for the MOZCENTRAL build, it's possible to easily stop bundling any CSS rules by using comments that include a `-webkit`-string. *Please note:* To easily test that this doesn't break the `errorWrapper` in GENERIC builds, try running e.g. `PDFViewerApplication._otherError("test");` in the web-console.
2022-04-20 21:21:51 +09:00
<div id="errorSpacer"></div>
Fix the error box.
2012-04-26 09:20:13 +09:00
<textarea id="errorMoreInfo" hidden='true' readonly="readonly"></textarea>
Switching to the document outline view if the document structure is present
2011-08-22 11:05:10 +09:00
</div>
Stop including the "errorWrapper" HTML code in `MOZCENTRAL`-builds Given that these HTML elements are not being used at all in `MOZCENTRAL`-builds, note the preprocessor check in `PDFViewerApplication._otherError`, we obviously don't need the HTML code either.
2021-02-14 18:39:34 +09:00
<!--#endif-->
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div> <!-- mainContainer -->
Make worker support work again after file split. Add PDFJS_WORKER_DIR/PDFJS_WORKER_FILE to specify where to load files if worker support is enabled
2011-10-28 21:32:36 +09:00
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
<div id="dialogContainer">
<dialog id="passwordDialog">
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<label for="password" id="passwordText" data-l10n-id="password_label">Enter the password to open this PDF file:</label>
Document properties
2014-01-22 08:07:07 +09:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
<div class="row">
<input type="password" id="password" class="toolbarField">
Improved password prompt
2013-09-25 00:46:54 +09:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
<div class="buttonRow">
<button id="passwordCancel" class="dialogButton"><span data-l10n-id="password_cancel">Cancel</span></button>
<button id="passwordSubmit" class="dialogButton"><span data-l10n-id="password_ok">OK</span></button>
</div>
</dialog>
<dialog id="documentPropertiesDialog">
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="fileNameLabel" data-l10n-id="document_properties_file_name">File name:</span>
<p id="fileNameField" aria-labelledby="fileNameLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="fileSizeLabel" data-l10n-id="document_properties_file_size">File size:</span>
<p id="fileSizeField" aria-labelledby="fileSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="separator"></div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="titleLabel" data-l10n-id="document_properties_title">Title:</span>
<p id="titleField" aria-labelledby="titleLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="authorLabel" data-l10n-id="document_properties_author">Author:</span>
<p id="authorField" aria-labelledby="authorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="subjectLabel" data-l10n-id="document_properties_subject">Subject:</span>
<p id="subjectField" aria-labelledby="subjectLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="keywordsLabel" data-l10n-id="document_properties_keywords">Keywords:</span>
<p id="keywordsField" aria-labelledby="keywordsLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="creationDateLabel" data-l10n-id="document_properties_creation_date">Creation Date:</span>
<p id="creationDateField" aria-labelledby="creationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="modificationDateLabel" data-l10n-id="document_properties_modification_date">Modification Date:</span>
<p id="modificationDateField" aria-labelledby="modificationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="creatorLabel" data-l10n-id="document_properties_creator">Creator:</span>
<p id="creatorField" aria-labelledby="creatorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="separator"></div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="producerLabel" data-l10n-id="document_properties_producer">PDF Producer:</span>
<p id="producerField" aria-labelledby="producerLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="versionLabel" data-l10n-id="document_properties_version">PDF Version:</span>
<p id="versionField" aria-labelledby="versionLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="pageCountLabel" data-l10n-id="document_properties_page_count">Page Count:</span>
<p id="pageCountField" aria-labelledby="pageCountLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="pageSizeLabel" data-l10n-id="document_properties_page_size">Page Size:</span>
<p id="pageSizeField" aria-labelledby="pageSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="separator"></div>
<div class="row">
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<span id="linearizedLabel" data-l10n-id="document_properties_linearized">Fast Web View:</span>
<p id="linearizedField" aria-labelledby="linearizedLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div>
<div class="buttonRow">
<button id="documentPropertiesClose" class="dialogButton"><span data-l10n-id="document_properties_close">Close</span></button>
</div>
</dialog>
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
<!--#if !MOZCENTRAL-->
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 22:10:28 +09:00
<dialog id="printServiceDialog" style="min-width: 200px;">
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
<div class="row">
<span data-l10n-id="print_progress_message">Preparing document for printing…</span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
<div class="row">
<progress value="0" max="100"></progress>
<span data-l10n-id="print_progress_percent" data-l10n-args='{ "progress": 0 }' class="relative-progress">0%</span>
</div>
<div class="buttonRow">
<button id="printCancel" class="dialogButton"><span data-l10n-id="print_progress_close">Cancel</span></button>
</div>
</dialog>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
<!--#endif-->
Teach users how to enable access to local files.
2015-07-19 00:11:33 +09:00
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-overlays.html-->
<!--#endif-->
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 22:10:13 +09:00
</div> <!-- dialogContainer -->
Improved password prompt
2013-09-25 00:46:54 +09:00
text selection OK, switch outline OK
2012-04-13 08:29:15 +09:00
</div> <!-- outerContainer -->
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
<div id="printContainer"></div>
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
Stop bundling the openFile-buttons in the CHROME build This is, for all intents and purposes, equivalent to PR 14833 and slightly reduces the size of the `gulp chromium` output.
2022-05-08 05:05:39 +09:00
<!--#if GENERIC-->
[GENERIC viewer] Re-factor the `fileInput` initialization *This is yet another installment in a never-ending series of patches that attempt to simplify and improve old code.* The `fileInput`-element is used to support the "Open file"-button in the `GENERIC` viewer, however this is very old code. Rather than creating the element dynamically in JavaScript, we can simply define it conditionally in the HTML code thanks to the pre-processor. Furthermore, the `fileInput`-element currently has a number of unnecessary CSS rules, since the element is *purposely* never made visibly. Note that with these changes, the `fileInput`-element will now *always* have `display: none;` set. This shouldn't matter, since we can still trigger the `click`-event of the element just fine (via JavaScript) and this patch has been successfully tested in both Mozilla Firefox and Google Chrome.
2022-04-09 23:30:02 +09:00
<input type="file" id="fileInput" class="hidden">
<!--#endif-->
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
</body>
Factor out mock tests, add browser test page, initial canvas backend
2011-05-05 09:32:59 +09:00
</html>
Reference in New Issue Copy Permalink