2014-10-01 00:48:29 +09:00
|
|
|
/* Copyright 2014 Mozilla Foundation
|
2012-09-01 07:48:21 +09:00
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
|
2014-10-01 00:48:29 +09:00
|
|
|
@import url(pdf_viewer.css);
|
|
|
|
|
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
:root {
|
2022-03-20 00:56:47 +09:00
|
|
|
--dir-factor: 1;
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
--sidebar-width: 200px;
|
Add support for CSS variables using the `PostCSS CSS Variables` package (issue 11462)
Having thought *briefly* about using `css-vars-ponyfill`, I'm no longer convinced that it'd be a good idea. The reason is that if we actually want to properly support CSS variables, then that functionality should be available in *all* of our CSS files.
Note in particular the `pdf_viewer.css` file that's built as part of the `COMPONENTS` target, in which case I really cannot see how a rewrite-at-the-client solution would ever be guaranteed to always work correctly and without accidentally touching other CSS in the surrounding application.
All-in-all, simply re-writing the CSS variables at build-time seems much easier and is thus the approach taken in this patch; courtesy of https://github.com/MadLittleMods/postcss-css-variables
By using its `preserve` option, the built files will thus include *both* a fallback and a modern `var(...)` format[1]. As a proof-of-concept this patch removes a couple of manually added fallback values, and converts an additional sidebar related property to use a CSS variable.
---
[1] Comparing the `master` branch with this patch, when using `gulp generic`, produces the following diff for the built `web/viewer.css` file:
```diff
@@ -408,6 +408,7 @@
:root {
--sidebar-width: 200px;
+ --sidebar-transition-duration: 200ms;
}
* {
@@ -550,27 +551,28 @@
position: absolute;
top: 32px;
bottom: 0;
- width: 200px; /* Here, and elsewhere below, keep the constant value for compatibility
- with older browsers that lack support for CSS variables. */
+ width: 200px;
width: var(--sidebar-width);
visibility: hidden;
z-index: 100;
border-top: 1px solid rgba(51, 51, 51, 1);
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
html[dir='ltr'] #sidebarContainer {
-webkit-transition-property: left;
transition-property: left;
- left: -200px;
+ left: calc(-1 * 200px);
left: calc(-1 * var(--sidebar-width));
}
html[dir='rtl'] #sidebarContainer {
-webkit-transition-property: right;
transition-property: right;
- right: -200px;
+ right: calc(-1 * 200px);
right: calc(-1 * var(--sidebar-width));
}
@@ -640,6 +642,8 @@
#viewerContainer:not(.pdfPresentationMode) {
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
```
2020-02-05 06:28:38 +09:00
|
|
|
--sidebar-transition-duration: 200ms;
|
|
|
|
|
--sidebar-transition-timing-function: ease;
|
2021-09-15 22:00:56 +09:00
|
|
|
--scale-select-container-width: 140px;
|
|
|
|
|
--scale-select-overflow: 22px;
|
2020-07-30 01:31:58 +09:00
|
|
|
|
|
|
|
|
--toolbar-icon-opacity: 0.7;
|
|
|
|
|
--doorhanger-icon-opacity: 0.9;
|
|
|
|
|
|
|
|
|
|
--main-color: rgba(12, 12, 13, 1);
|
|
|
|
|
--body-bg-color: rgba(237, 237, 240, 1);
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if !MOZCENTRAL*/
|
|
|
|
|
--errorWrapper-bg-color: rgba(255, 110, 110, 1);
|
|
|
|
|
/*#endif*/
|
2022-05-14 20:10:13 +09:00
|
|
|
--progressBar-percent: 0%;
|
|
|
|
|
--progressBar-end-offset: 0;
|
2020-07-30 01:31:58 +09:00
|
|
|
--progressBar-color: rgba(10, 132, 255, 1);
|
2020-08-28 23:04:43 +09:00
|
|
|
--progressBar-indeterminate-bg-color: rgba(221, 221, 222, 1);
|
|
|
|
|
--progressBar-indeterminate-blend-color: rgba(116, 177, 239, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--scrollbar-color: auto;
|
|
|
|
|
--scrollbar-bg-color: auto;
|
2020-11-29 23:32:15 +09:00
|
|
|
--toolbar-icon-bg-color: rgba(0, 0, 0, 1);
|
2021-04-10 21:02:24 +09:00
|
|
|
--toolbar-icon-hover-bg-color: rgba(0, 0, 0, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
|
2021-03-02 02:27:27 +09:00
|
|
|
--sidebar-narrow-bg-color: rgba(237, 237, 240, 0.9);
|
|
|
|
|
--sidebar-toolbar-bg-color: rgba(245, 246, 247, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toolbar-bg-color: rgba(249, 249, 250, 1);
|
|
|
|
|
--toolbar-border-color: rgba(204, 204, 204, 1);
|
|
|
|
|
--button-hover-color: rgba(221, 222, 223, 1);
|
2021-04-10 21:02:24 +09:00
|
|
|
--toggled-btn-color: rgba(0, 0, 0, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toggled-btn-bg-color: rgba(0, 0, 0, 0.3);
|
2021-01-03 22:42:40 +09:00
|
|
|
--toggled-hover-active-btn-color: rgba(0, 0, 0, 0.4);
|
2020-07-30 01:31:58 +09:00
|
|
|
--dropdown-btn-bg-color: rgba(215, 215, 219, 1);
|
|
|
|
|
--separator-color: rgba(0, 0, 0, 0.3);
|
|
|
|
|
--field-color: rgba(6, 6, 6, 1);
|
|
|
|
|
--field-bg-color: rgba(255, 255, 255, 1);
|
|
|
|
|
--field-border-color: rgba(187, 187, 188, 1);
|
2020-09-06 06:06:44 +09:00
|
|
|
--treeitem-color: rgba(0, 0, 0, 0.8);
|
|
|
|
|
--treeitem-hover-color: rgba(0, 0, 0, 0.9);
|
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
|
|
|
--treeitem-selected-color: rgba(0, 0, 0, 0.9);
|
|
|
|
|
--treeitem-selected-bg-color: rgba(0, 0, 0, 0.25);
|
2020-07-30 01:31:58 +09:00
|
|
|
--sidebaritem-bg-color: rgba(0, 0, 0, 0.15);
|
|
|
|
|
--doorhanger-bg-color: rgba(255, 255, 255, 1);
|
|
|
|
|
--doorhanger-border-color: rgba(12, 12, 13, 0.2);
|
2021-04-10 21:02:24 +09:00
|
|
|
--doorhanger-hover-color: rgba(12, 12, 13, 1);
|
|
|
|
|
--doorhanger-hover-bg-color: rgba(237, 237, 237, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--doorhanger-separator-color: rgba(222, 222, 222, 1);
|
2022-03-25 22:10:13 +09:00
|
|
|
--dialog-button-border: 0 none;
|
|
|
|
|
--dialog-button-bg-color: rgba(12, 12, 13, 0.1);
|
|
|
|
|
--dialog-button-hover-bg-color: rgba(12, 12, 13, 0.3);
|
2020-07-30 01:31:58 +09:00
|
|
|
|
|
|
|
|
--loading-icon: url(images/loading.svg);
|
|
|
|
|
--treeitem-expanded-icon: url(images/treeitem-expanded.svg);
|
|
|
|
|
--treeitem-collapsed-icon: url(images/treeitem-collapsed.svg);
|
2022-06-05 17:00:08 +09:00
|
|
|
--toolbarButton-editorFreeText-icon: url(images/toolbarButton-editorFreeText.svg);
|
2022-06-05 06:28:19 +09:00
|
|
|
--toolbarButton-editorInk-icon: url(images/toolbarButton-editorInk.svg);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toolbarButton-menuArrow-icon: url(images/toolbarButton-menuArrow.svg);
|
|
|
|
|
--toolbarButton-sidebarToggle-icon: url(images/toolbarButton-sidebarToggle.svg);
|
|
|
|
|
--toolbarButton-secondaryToolbarToggle-icon: url(images/toolbarButton-secondaryToolbarToggle.svg);
|
|
|
|
|
--toolbarButton-pageUp-icon: url(images/toolbarButton-pageUp.svg);
|
|
|
|
|
--toolbarButton-pageDown-icon: url(images/toolbarButton-pageDown.svg);
|
|
|
|
|
--toolbarButton-zoomOut-icon: url(images/toolbarButton-zoomOut.svg);
|
|
|
|
|
--toolbarButton-zoomIn-icon: url(images/toolbarButton-zoomIn.svg);
|
|
|
|
|
--toolbarButton-presentationMode-icon: url(images/toolbarButton-presentationMode.svg);
|
|
|
|
|
--toolbarButton-print-icon: url(images/toolbarButton-print.svg);
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if GENERIC*/
|
|
|
|
|
--toolbarButton-openFile-icon: url(images/toolbarButton-openFile.svg);
|
|
|
|
|
/*#endif*/
|
2020-07-30 01:31:58 +09:00
|
|
|
--toolbarButton-download-icon: url(images/toolbarButton-download.svg);
|
|
|
|
|
--toolbarButton-bookmark-icon: url(images/toolbarButton-bookmark.svg);
|
|
|
|
|
--toolbarButton-viewThumbnail-icon: url(images/toolbarButton-viewThumbnail.svg);
|
|
|
|
|
--toolbarButton-viewOutline-icon: url(images/toolbarButton-viewOutline.svg);
|
|
|
|
|
--toolbarButton-viewAttachments-icon: url(images/toolbarButton-viewAttachments.svg);
|
[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
|
|
|
--toolbarButton-viewLayers-icon: url(images/toolbarButton-viewLayers.svg);
|
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
|
|
|
--toolbarButton-currentOutlineItem-icon: url(images/toolbarButton-currentOutlineItem.svg);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toolbarButton-search-icon: url(images/toolbarButton-search.svg);
|
|
|
|
|
--findbarButton-previous-icon: url(images/findbarButton-previous.svg);
|
|
|
|
|
--findbarButton-next-icon: url(images/findbarButton-next.svg);
|
|
|
|
|
--secondaryToolbarButton-firstPage-icon: url(images/secondaryToolbarButton-firstPage.svg);
|
|
|
|
|
--secondaryToolbarButton-lastPage-icon: url(images/secondaryToolbarButton-lastPage.svg);
|
|
|
|
|
--secondaryToolbarButton-rotateCcw-icon: url(images/secondaryToolbarButton-rotateCcw.svg);
|
|
|
|
|
--secondaryToolbarButton-rotateCw-icon: url(images/secondaryToolbarButton-rotateCw.svg);
|
|
|
|
|
--secondaryToolbarButton-selectTool-icon: url(images/secondaryToolbarButton-selectTool.svg);
|
|
|
|
|
--secondaryToolbarButton-handTool-icon: url(images/secondaryToolbarButton-handTool.svg);
|
2021-10-07 21:04:41 +09:00
|
|
|
--secondaryToolbarButton-scrollPage-icon: url(images/secondaryToolbarButton-scrollPage.svg);
|
2020-07-30 01:31:58 +09:00
|
|
|
--secondaryToolbarButton-scrollVertical-icon: url(images/secondaryToolbarButton-scrollVertical.svg);
|
|
|
|
|
--secondaryToolbarButton-scrollHorizontal-icon: url(images/secondaryToolbarButton-scrollHorizontal.svg);
|
|
|
|
|
--secondaryToolbarButton-scrollWrapped-icon: url(images/secondaryToolbarButton-scrollWrapped.svg);
|
|
|
|
|
--secondaryToolbarButton-spreadNone-icon: url(images/secondaryToolbarButton-spreadNone.svg);
|
|
|
|
|
--secondaryToolbarButton-spreadOdd-icon: url(images/secondaryToolbarButton-spreadOdd.svg);
|
|
|
|
|
--secondaryToolbarButton-spreadEven-icon: url(images/secondaryToolbarButton-spreadEven.svg);
|
|
|
|
|
--secondaryToolbarButton-documentProperties-icon: url(images/secondaryToolbarButton-documentProperties.svg);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-20 00:56:47 +09:00
|
|
|
:root:dir(rtl) {
|
|
|
|
|
--dir-factor: -1;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-30 01:31:58 +09:00
|
|
|
@media (prefers-color-scheme: dark) {
|
|
|
|
|
:root {
|
|
|
|
|
--main-color: rgba(249, 249, 250, 1);
|
|
|
|
|
--body-bg-color: rgba(42, 42, 46, 1);
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if !MOZCENTRAL*/
|
|
|
|
|
--errorWrapper-bg-color: rgba(169, 14, 14, 1);
|
|
|
|
|
/*#endif*/
|
2020-07-30 01:31:58 +09:00
|
|
|
--progressBar-color: rgba(0, 96, 223, 1);
|
2020-08-28 23:04:43 +09:00
|
|
|
--progressBar-indeterminate-bg-color: rgba(40, 40, 43, 1);
|
|
|
|
|
--progressBar-indeterminate-blend-color: rgba(20, 68, 133, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--scrollbar-color: rgba(121, 121, 123, 1);
|
|
|
|
|
--scrollbar-bg-color: rgba(35, 35, 39, 1);
|
2020-11-29 23:32:15 +09:00
|
|
|
--toolbar-icon-bg-color: rgba(255, 255, 255, 1);
|
2021-04-10 21:02:24 +09:00
|
|
|
--toolbar-icon-hover-bg-color: rgba(255, 255, 255, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
|
2021-03-02 02:27:27 +09:00
|
|
|
--sidebar-narrow-bg-color: rgba(42, 42, 46, 0.9);
|
|
|
|
|
--sidebar-toolbar-bg-color: rgba(50, 50, 52, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toolbar-bg-color: rgba(56, 56, 61, 1);
|
|
|
|
|
--toolbar-border-color: rgba(12, 12, 13, 1);
|
|
|
|
|
--button-hover-color: rgba(102, 102, 103, 1);
|
2021-04-10 21:02:24 +09:00
|
|
|
--toggled-btn-color: rgba(255, 255, 255, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--toggled-btn-bg-color: rgba(0, 0, 0, 0.3);
|
2021-01-03 22:42:40 +09:00
|
|
|
--toggled-hover-active-btn-color: rgba(0, 0, 0, 0.4);
|
2020-07-30 01:31:58 +09:00
|
|
|
--dropdown-btn-bg-color: rgba(74, 74, 79, 1);
|
|
|
|
|
--separator-color: rgba(0, 0, 0, 0.3);
|
|
|
|
|
--field-color: rgba(250, 250, 250, 1);
|
|
|
|
|
--field-bg-color: rgba(64, 64, 68, 1);
|
|
|
|
|
--field-border-color: rgba(115, 115, 115, 1);
|
2020-09-06 06:06:44 +09:00
|
|
|
--treeitem-color: rgba(255, 255, 255, 0.8);
|
|
|
|
|
--treeitem-hover-color: rgba(255, 255, 255, 0.9);
|
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
|
|
|
--treeitem-selected-color: rgba(255, 255, 255, 0.9);
|
|
|
|
|
--treeitem-selected-bg-color: rgba(255, 255, 255, 0.25);
|
2020-07-30 01:31:58 +09:00
|
|
|
--sidebaritem-bg-color: rgba(255, 255, 255, 0.15);
|
|
|
|
|
--doorhanger-bg-color: rgba(74, 74, 79, 1);
|
|
|
|
|
--doorhanger-border-color: rgba(39, 39, 43, 1);
|
2021-04-10 21:02:24 +09:00
|
|
|
--doorhanger-hover-color: rgba(249, 249, 250, 1);
|
|
|
|
|
--doorhanger-hover-bg-color: rgba(93, 94, 98, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
--doorhanger-separator-color: rgba(92, 92, 97, 1);
|
2022-03-25 22:10:13 +09:00
|
|
|
--dialog-button-bg-color: rgba(92, 92, 97, 1);
|
|
|
|
|
--dialog-button-hover-bg-color: rgba(115, 115, 115, 1);
|
2020-07-30 01:31:58 +09:00
|
|
|
|
2020-11-29 23:32:15 +09:00
|
|
|
/* This image is used in <input> elements, which unfortunately means that
|
|
|
|
|
* the `mask-image` approach used with all of the other images doesn't work
|
|
|
|
|
* here; hence why we still have two versions of this particular image. */
|
2020-07-30 01:31:58 +09:00
|
|
|
--loading-icon: url(images/loading-dark.svg);
|
|
|
|
|
}
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
}
|
|
|
|
|
|
2021-04-10 21:02:24 +09:00
|
|
|
@media screen and (forced-colors: active) {
|
|
|
|
|
:root {
|
|
|
|
|
--button-hover-color: Highlight;
|
|
|
|
|
--doorhanger-hover-bg-color: Highlight;
|
|
|
|
|
--toolbar-icon-opacity: 1;
|
|
|
|
|
--toolbar-icon-bg-color: ButtonText;
|
|
|
|
|
--toolbar-icon-hover-bg-color: ButtonFace;
|
|
|
|
|
--toggled-btn-color: HighlightText;
|
|
|
|
|
--toggled-btn-bg-color: LinkText;
|
|
|
|
|
--doorhanger-hover-color: ButtonFace;
|
|
|
|
|
--doorhanger-border-color-whcm: 1px solid ButtonText;
|
|
|
|
|
--doorhanger-triangle-opacity-whcm: 0;
|
2022-03-25 22:10:13 +09:00
|
|
|
--dialog-button-border: 1px solid Highlight;
|
|
|
|
|
--dialog-button-hover-bg-color: Highlight;
|
|
|
|
|
--dialog-button-hover-color: ButtonFace;
|
2021-04-10 21:02:24 +09:00
|
|
|
--field-border-color: ButtonText;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
* {
|
|
|
|
|
padding: 0;
|
|
|
|
|
margin: 0;
|
|
|
|
|
}
|
2011-05-26 23:02:52 +09:00
|
|
|
|
2022-04-17 20:52:57 +09:00
|
|
|
html,
|
|
|
|
|
body {
|
2012-04-12 08:12:51 +09:00
|
|
|
height: 100%;
|
2016-02-11 06:10:03 +09:00
|
|
|
width: 100%;
|
2011-05-26 23:02:52 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--body-bg-color);
|
2012-06-13 18:15:31 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
body,
|
|
|
|
|
input,
|
2012-06-13 18:27:22 +09:00
|
|
|
button,
|
2012-06-13 18:15:31 +09:00
|
|
|
select {
|
2012-06-14 02:47:46 +09:00
|
|
|
font: message-box;
|
2014-01-27 19:57:33 +09:00
|
|
|
outline: none;
|
2020-07-30 01:31:58 +09:00
|
|
|
scrollbar-color: var(--scrollbar-color) var(--scrollbar-bg-color);
|
2011-05-26 23:02:52 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-17 20:52:57 +09:00
|
|
|
.hidden,
|
2011-10-19 04:40:59 +09:00
|
|
|
[hidden] {
|
2012-01-25 08:13:50 +09:00
|
|
|
display: none !important;
|
2011-10-19 04:40:59 +09:00
|
|
|
}
|
|
|
|
|
|
2015-02-04 22:10:45 +09:00
|
|
|
#viewerContainer.pdfPresentationMode:fullscreen {
|
2021-01-10 22:02:38 +09:00
|
|
|
top: 0;
|
2019-12-26 00:16:13 +09:00
|
|
|
background-color: rgba(0, 0, 0, 1);
|
2012-07-31 00:12:49 +09:00
|
|
|
width: 100%;
|
|
|
|
|
height: 100%;
|
2012-10-11 09:32:48 +09:00
|
|
|
overflow: hidden;
|
|
|
|
|
cursor: none;
|
2018-04-04 07:18:57 +09:00
|
|
|
user-select: none;
|
2013-09-11 04:40:14 +09:00
|
|
|
}
|
|
|
|
|
|
2015-02-04 22:10:45 +09:00
|
|
|
.pdfPresentationMode:fullscreen a:not(.internalLink) {
|
2013-03-26 01:50:49 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-01 07:07:02 +09:00
|
|
|
.pdfPresentationMode:fullscreen .textLayer span {
|
2015-02-04 22:10:45 +09:00
|
|
|
cursor: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.pdfPresentationMode.pdfPresentationModeControls > *,
|
2021-04-01 07:07:02 +09:00
|
|
|
.pdfPresentationMode.pdfPresentationModeControls .textLayer span {
|
2012-10-11 09:32:48 +09:00
|
|
|
cursor: default;
|
2012-07-31 00:12:49 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
#outerContainer {
|
2011-07-29 02:48:05 +09:00
|
|
|
width: 100%;
|
2012-04-12 08:12:51 +09:00
|
|
|
height: 100%;
|
2013-10-10 07:04:58 +09:00
|
|
|
position: relative;
|
2011-05-26 23:02:52 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
#sidebarContainer {
|
2012-04-26 03:34:28 +09:00
|
|
|
position: absolute;
|
2017-09-30 23:41:46 +09:00
|
|
|
top: 32px;
|
2012-04-26 03:34:28 +09:00
|
|
|
bottom: 0;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-start: calc(-1 * var(--sidebar-width));
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
width: var(--sidebar-width);
|
2012-05-02 01:43:48 +09:00
|
|
|
visibility: hidden;
|
2017-09-30 23:41:46 +09:00
|
|
|
z-index: 100;
|
2019-12-26 00:16:13 +09:00
|
|
|
border-top: 1px solid rgba(51, 51, 51, 1);
|
2022-03-17 19:43:32 +09:00
|
|
|
border-inline-end: var(--doorhanger-border-color-whcm);
|
2022-03-17 19:18:47 +09:00
|
|
|
transition-property: inset-inline-start;
|
Add support for CSS variables using the `PostCSS CSS Variables` package (issue 11462)
Having thought *briefly* about using `css-vars-ponyfill`, I'm no longer convinced that it'd be a good idea. The reason is that if we actually want to properly support CSS variables, then that functionality should be available in *all* of our CSS files.
Note in particular the `pdf_viewer.css` file that's built as part of the `COMPONENTS` target, in which case I really cannot see how a rewrite-at-the-client solution would ever be guaranteed to always work correctly and without accidentally touching other CSS in the surrounding application.
All-in-all, simply re-writing the CSS variables at build-time seems much easier and is thus the approach taken in this patch; courtesy of https://github.com/MadLittleMods/postcss-css-variables
By using its `preserve` option, the built files will thus include *both* a fallback and a modern `var(...)` format[1]. As a proof-of-concept this patch removes a couple of manually added fallback values, and converts an additional sidebar related property to use a CSS variable.
---
[1] Comparing the `master` branch with this patch, when using `gulp generic`, produces the following diff for the built `web/viewer.css` file:
```diff
@@ -408,6 +408,7 @@
:root {
--sidebar-width: 200px;
+ --sidebar-transition-duration: 200ms;
}
* {
@@ -550,27 +551,28 @@
position: absolute;
top: 32px;
bottom: 0;
- width: 200px; /* Here, and elsewhere below, keep the constant value for compatibility
- with older browsers that lack support for CSS variables. */
+ width: 200px;
width: var(--sidebar-width);
visibility: hidden;
z-index: 100;
border-top: 1px solid rgba(51, 51, 51, 1);
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
html[dir='ltr'] #sidebarContainer {
-webkit-transition-property: left;
transition-property: left;
- left: -200px;
+ left: calc(-1 * 200px);
left: calc(-1 * var(--sidebar-width));
}
html[dir='rtl'] #sidebarContainer {
-webkit-transition-property: right;
transition-property: right;
- right: -200px;
+ right: calc(-1 * 200px);
right: calc(-1 * var(--sidebar-width));
}
@@ -640,6 +642,8 @@
#viewerContainer:not(.pdfPresentationMode) {
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
```
2020-02-05 06:28:38 +09:00
|
|
|
transition-duration: var(--sidebar-transition-duration);
|
|
|
|
|
transition-timing-function: var(--sidebar-transition-timing-function);
|
2012-04-26 03:34:28 +09:00
|
|
|
}
|
2011-05-26 23:02:52 +09:00
|
|
|
|
2017-09-30 23:41:46 +09:00
|
|
|
#outerContainer.sidebarMoving #sidebarContainer,
|
|
|
|
|
#outerContainer.sidebarOpen #sidebarContainer {
|
2012-05-02 01:43:48 +09:00
|
|
|
visibility: visible;
|
2012-05-02 07:19:02 +09:00
|
|
|
}
|
2022-03-17 19:18:47 +09:00
|
|
|
#outerContainer.sidebarOpen #sidebarContainer {
|
|
|
|
|
inset-inline-start: 0;
|
2011-10-15 11:05:57 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-26 03:34:28 +09:00
|
|
|
#mainContainer {
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 0;
|
|
|
|
|
right: 0;
|
|
|
|
|
bottom: 0;
|
|
|
|
|
left: 0;
|
2022-07-01 20:27:13 +09:00
|
|
|
min-width: 350px;
|
2012-05-02 07:08:30 +09:00
|
|
|
}
|
2012-04-26 03:34:28 +09:00
|
|
|
|
|
|
|
|
#sidebarContent {
|
2012-04-26 04:14:09 +09:00
|
|
|
top: 32px;
|
2012-04-26 03:34:28 +09:00
|
|
|
bottom: 0;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-start: 0;
|
2012-04-26 03:34:28 +09:00
|
|
|
overflow: auto;
|
|
|
|
|
position: absolute;
|
2017-09-30 23:41:46 +09:00
|
|
|
width: 100%;
|
2019-12-25 22:15:39 +09:00
|
|
|
background-color: rgba(0, 0, 0, 0.1);
|
2022-03-20 00:56:47 +09:00
|
|
|
box-shadow: inset calc(-1px * var(--dir-factor)) 0 0 rgba(0, 0, 0, 0.25);
|
2011-08-29 05:10:14 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
#viewerContainer {
|
2012-04-26 03:34:28 +09:00
|
|
|
overflow: auto;
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 32px;
|
|
|
|
|
right: 0;
|
|
|
|
|
bottom: 0;
|
|
|
|
|
left: 0;
|
2013-07-06 22:37:03 +09:00
|
|
|
outline: none;
|
2018-06-14 23:09:22 +09:00
|
|
|
}
|
|
|
|
|
#viewerContainer:not(.pdfPresentationMode) {
|
Add support for CSS variables using the `PostCSS CSS Variables` package (issue 11462)
Having thought *briefly* about using `css-vars-ponyfill`, I'm no longer convinced that it'd be a good idea. The reason is that if we actually want to properly support CSS variables, then that functionality should be available in *all* of our CSS files.
Note in particular the `pdf_viewer.css` file that's built as part of the `COMPONENTS` target, in which case I really cannot see how a rewrite-at-the-client solution would ever be guaranteed to always work correctly and without accidentally touching other CSS in the surrounding application.
All-in-all, simply re-writing the CSS variables at build-time seems much easier and is thus the approach taken in this patch; courtesy of https://github.com/MadLittleMods/postcss-css-variables
By using its `preserve` option, the built files will thus include *both* a fallback and a modern `var(...)` format[1]. As a proof-of-concept this patch removes a couple of manually added fallback values, and converts an additional sidebar related property to use a CSS variable.
---
[1] Comparing the `master` branch with this patch, when using `gulp generic`, produces the following diff for the built `web/viewer.css` file:
```diff
@@ -408,6 +408,7 @@
:root {
--sidebar-width: 200px;
+ --sidebar-transition-duration: 200ms;
}
* {
@@ -550,27 +551,28 @@
position: absolute;
top: 32px;
bottom: 0;
- width: 200px; /* Here, and elsewhere below, keep the constant value for compatibility
- with older browsers that lack support for CSS variables. */
+ width: 200px;
width: var(--sidebar-width);
visibility: hidden;
z-index: 100;
border-top: 1px solid rgba(51, 51, 51, 1);
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
html[dir='ltr'] #sidebarContainer {
-webkit-transition-property: left;
transition-property: left;
- left: -200px;
+ left: calc(-1 * 200px);
left: calc(-1 * var(--sidebar-width));
}
html[dir='rtl'] #sidebarContainer {
-webkit-transition-property: right;
transition-property: right;
- right: -200px;
+ right: calc(-1 * 200px);
right: calc(-1 * var(--sidebar-width));
}
@@ -640,6 +642,8 @@
#viewerContainer:not(.pdfPresentationMode) {
-webkit-transition-duration: 200ms;
transition-duration: 200ms;
+ -webkit-transition-duration: var(--sidebar-transition-duration);
+ transition-duration: var(--sidebar-transition-duration);
-webkit-transition-timing-function: ease;
transition-timing-function: ease;
}
```
2020-02-05 06:28:38 +09:00
|
|
|
transition-duration: var(--sidebar-transition-duration);
|
|
|
|
|
transition-timing-function: var(--sidebar-transition-timing-function);
|
2011-05-26 23:02:52 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-17 19:18:47 +09:00
|
|
|
#outerContainer.sidebarOpen #viewerContainer:not(.pdfPresentationMode) {
|
|
|
|
|
inset-inline-start: var(--sidebar-width);
|
|
|
|
|
transition-property: inset-inline-start;
|
2017-09-30 23:41:46 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbar {
|
2013-02-07 08:19:29 +09:00
|
|
|
position: relative;
|
2012-04-26 03:34:28 +09:00
|
|
|
left: 0;
|
|
|
|
|
right: 0;
|
2012-04-12 08:12:51 +09:00
|
|
|
z-index: 9999;
|
|
|
|
|
cursor: default;
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
#toolbarContainer {
|
|
|
|
|
width: 100%;
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
#toolbarSidebar {
|
2017-09-30 23:41:46 +09:00
|
|
|
width: 100%;
|
2012-10-30 06:35:07 +09:00
|
|
|
height: 32px;
|
2021-03-02 02:27:27 +09:00
|
|
|
background-color: var(--sidebar-toolbar-bg-color);
|
2022-03-20 00:56:47 +09:00
|
|
|
box-shadow: inset calc(-1px * var(--dir-factor)) 0 0 rgba(0, 0, 0, 0.25),
|
|
|
|
|
0 1px 0 rgba(0, 0, 0, 0.15), 0 0 1px rgba(0, 0, 0, 0.1);
|
2020-07-30 01:31:58 +09:00
|
|
|
}
|
|
|
|
|
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
#sidebarResizer {
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 0;
|
|
|
|
|
bottom: 0;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-end: -6px;
|
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072)
By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code.
Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar.
However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem.
Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`.
*Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome.
Fixes 2072.
2017-10-10 23:16:05 +09:00
|
|
|
width: 6px;
|
|
|
|
|
z-index: 200;
|
|
|
|
|
cursor: ew-resize;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-30 23:24:55 +09:00
|
|
|
#toolbarContainer,
|
|
|
|
|
.findbar,
|
2022-06-14 01:23:10 +09:00
|
|
|
.secondaryToolbar,
|
|
|
|
|
.editorParamsToolbar {
|
2012-04-26 03:34:28 +09:00
|
|
|
position: relative;
|
2012-04-12 08:12:51 +09:00
|
|
|
height: 32px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--toolbar-bg-color);
|
|
|
|
|
box-shadow: 0 1px 0 var(--toolbar-border-color);
|
2014-01-22 06:56:19 +09:00
|
|
|
}
|
2012-09-12 01:30:44 +09:00
|
|
|
|
2013-02-07 08:19:29 +09:00
|
|
|
#toolbarViewer {
|
|
|
|
|
height: 32px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#loadingBar {
|
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
|
|
|
position: absolute;
|
2022-05-14 20:10:13 +09:00
|
|
|
inset-inline: 0 var(--progressBar-end-offset);
|
2014-08-12 13:09:38 +09:00
|
|
|
height: 4px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--body-bg-color);
|
2020-08-28 23:04:43 +09:00
|
|
|
border-bottom: 1px solid var(--toolbar-border-color);
|
2022-03-17 19:18:47 +09:00
|
|
|
transition-property: inset-inline-start;
|
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
|
|
|
transition-duration: var(--sidebar-transition-duration);
|
|
|
|
|
transition-timing-function: var(--sidebar-transition-timing-function);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-17 19:18:47 +09:00
|
|
|
#outerContainer.sidebarOpen #loadingBar {
|
|
|
|
|
inset-inline-start: var(--sidebar-width);
|
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
|
|
|
}
|
|
|
|
|
|
2013-02-07 08:19:29 +09:00
|
|
|
#loadingBar .progress {
|
|
|
|
|
position: absolute;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
2022-05-11 00:51:07 +09:00
|
|
|
width: 100%;
|
|
|
|
|
transform: scaleX(var(--progressBar-percent));
|
|
|
|
|
transform-origin: 0 0;
|
2013-02-07 08:19:29 +09:00
|
|
|
height: 100%;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--progressBar-color);
|
2013-02-07 08:19:29 +09:00
|
|
|
overflow: hidden;
|
2022-05-11 00:51:07 +09:00
|
|
|
transition: transform 200ms;
|
2013-02-07 08:19:29 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@keyframes progressIndeterminate {
|
2020-08-30 23:24:55 +09:00
|
|
|
0% {
|
2022-05-11 00:51:07 +09:00
|
|
|
transform: translateX(-142px);
|
2020-08-30 23:24:55 +09:00
|
|
|
}
|
|
|
|
|
100% {
|
2022-05-11 00:51:07 +09:00
|
|
|
transform: translateX(0);
|
2020-08-30 23:24:55 +09:00
|
|
|
}
|
2013-02-07 08:19:29 +09:00
|
|
|
}
|
|
|
|
|
|
2022-07-01 17:14:57 +09:00
|
|
|
#loadingBar.indeterminate .progress {
|
2022-05-11 00:51:07 +09:00
|
|
|
transform: none;
|
2020-08-28 23:04:43 +09:00
|
|
|
background-color: var(--progressBar-indeterminate-bg-color);
|
2013-02-07 08:19:29 +09:00
|
|
|
transition: none;
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-01 17:14:57 +09:00
|
|
|
#loadingBar.indeterminate .progress .glimmer {
|
2013-02-07 08:19:29 +09:00
|
|
|
position: absolute;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
|
|
|
|
height: 100%;
|
2015-11-01 22:19:59 +09:00
|
|
|
width: calc(100% + 150px);
|
2020-08-30 23:24:55 +09:00
|
|
|
background: repeating-linear-gradient(
|
|
|
|
|
135deg,
|
|
|
|
|
var(--progressBar-indeterminate-blend-color) 0,
|
|
|
|
|
var(--progressBar-indeterminate-bg-color) 5px,
|
|
|
|
|
var(--progressBar-indeterminate-bg-color) 45px,
|
|
|
|
|
var(--progressBar-color) 55px,
|
|
|
|
|
var(--progressBar-color) 95px,
|
|
|
|
|
var(--progressBar-indeterminate-blend-color) 100px
|
|
|
|
|
);
|
2020-08-28 23:04:43 +09:00
|
|
|
animation: progressIndeterminate 1s linear infinite;
|
2013-02-07 08:19:29 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-17 20:52:57 +09:00
|
|
|
#outerContainer.sidebarResizing #sidebarContainer,
|
|
|
|
|
#outerContainer.sidebarResizing #viewerContainer,
|
|
|
|
|
#outerContainer.sidebarResizing #loadingBar {
|
|
|
|
|
/* Improve responsiveness and avoid visual glitches when the sidebar is resized. */
|
|
|
|
|
transition-duration: 0s;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-30 23:24:55 +09:00
|
|
|
.findbar,
|
2022-06-14 01:23:10 +09:00
|
|
|
.secondaryToolbar,
|
|
|
|
|
.editorParamsToolbar {
|
2012-09-29 04:30:07 +09:00
|
|
|
top: 32px;
|
2012-09-12 01:30:44 +09:00
|
|
|
position: absolute;
|
2012-09-29 04:30:07 +09:00
|
|
|
z-index: 10000;
|
2017-03-09 07:54:28 +09:00
|
|
|
height: auto;
|
2021-01-22 22:36:02 +09:00
|
|
|
padding: 0 4px;
|
|
|
|
|
margin: 4px 2px;
|
2012-09-12 01:30:44 +09:00
|
|
|
font-size: 12px;
|
|
|
|
|
line-height: 14px;
|
|
|
|
|
text-align: left;
|
2012-09-29 03:18:45 +09:00
|
|
|
cursor: default;
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-09 07:54:28 +09:00
|
|
|
.findbar {
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-start: 64px;
|
2017-03-09 07:54:28 +09:00
|
|
|
min-width: 300px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--toolbar-bg-color);
|
2017-03-09 07:54:28 +09:00
|
|
|
}
|
|
|
|
|
.findbar > div {
|
|
|
|
|
height: 32px;
|
|
|
|
|
}
|
2022-04-19 20:43:24 +09:00
|
|
|
.findbar > div#findbarInputContainer {
|
|
|
|
|
margin-inline-end: 4px;
|
|
|
|
|
}
|
2022-04-01 06:12:56 +09:00
|
|
|
.findbar.wrapContainers > div,
|
|
|
|
|
.findbar.wrapContainers > div#findbarMessageContainer > * {
|
2017-03-09 07:54:57 +09:00
|
|
|
clear: both;
|
|
|
|
|
}
|
2022-04-01 06:12:56 +09:00
|
|
|
.findbar.wrapContainers > div#findbarMessageContainer {
|
2017-03-09 07:54:57 +09:00
|
|
|
height: auto;
|
|
|
|
|
}
|
2020-07-30 01:31:58 +09:00
|
|
|
|
2020-08-29 22:27:00 +09:00
|
|
|
.findbar input[type="checkbox"] {
|
|
|
|
|
pointer-events: none;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-29 03:18:45 +09:00
|
|
|
.findbar label {
|
2018-04-04 07:18:57 +09:00
|
|
|
user-select: none;
|
2012-09-29 03:18:45 +09:00
|
|
|
}
|
|
|
|
|
|
2020-08-29 22:27:00 +09:00
|
|
|
.findbar label:hover,
|
2022-01-31 00:10:32 +09:00
|
|
|
.findbar input:focus-visible + label {
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--toggled-btn-color);
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--button-hover-color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.findbar .toolbarField[type="checkbox"]:checked + .toolbarLabel {
|
|
|
|
|
background-color: var(--toggled-btn-bg-color) !important;
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--toggled-btn-color);
|
2020-07-30 01:31:58 +09:00
|
|
|
}
|
|
|
|
|
|
2017-03-09 07:53:59 +09:00
|
|
|
#findInput {
|
|
|
|
|
width: 200px;
|
|
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if !MOZCENTRAL*/
|
2017-03-09 07:53:59 +09:00
|
|
|
#findInput::-webkit-input-placeholder {
|
2019-12-25 21:28:04 +09:00
|
|
|
color: rgba(191, 191, 191, 1);
|
2017-03-09 07:53:59 +09:00
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#endif*/
|
2017-03-09 07:53:59 +09:00
|
|
|
#findInput::placeholder {
|
2020-07-30 01:31:58 +09:00
|
|
|
font-style: normal;
|
2017-03-09 07:53:59 +09:00
|
|
|
}
|
2012-10-11 07:46:04 +09:00
|
|
|
#findInput[data-status="pending"] {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-image: var(--loading-icon);
|
2012-10-11 05:58:14 +09:00
|
|
|
background-repeat: no-repeat;
|
2022-03-20 00:56:47 +09:00
|
|
|
background-position: calc(50% + 48% * var(--dir-factor));
|
2014-08-26 05:58:44 +09:00
|
|
|
}
|
2020-12-02 23:23:20 +09:00
|
|
|
#findInput[data-status="notFound"] {
|
|
|
|
|
background-color: rgba(255, 102, 102, 1);
|
|
|
|
|
}
|
2012-10-11 05:58:14 +09:00
|
|
|
|
2022-06-14 01:23:10 +09:00
|
|
|
.secondaryToolbar,
|
|
|
|
|
.editorParamsToolbar {
|
2021-01-22 22:36:02 +09:00
|
|
|
padding: 6px 0 10px;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-end: 4px;
|
2013-09-05 06:48:31 +09:00
|
|
|
height: auto;
|
|
|
|
|
z-index: 30000;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--doorhanger-bg-color);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-06-14 01:23:10 +09:00
|
|
|
.editorParamsToolbarContainer {
|
|
|
|
|
width: 220px;
|
|
|
|
|
margin-bottom: -4px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.editorParamsToolbarContainer > .editorParamsSetter {
|
|
|
|
|
min-height: 26px;
|
|
|
|
|
display: flex;
|
|
|
|
|
align-items: center;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
padding-inline: 10px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsLabel {
|
|
|
|
|
padding-inline-end: 10px;
|
|
|
|
|
flex: none;
|
|
|
|
|
color: var(--main-color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsColor {
|
|
|
|
|
width: 32px;
|
|
|
|
|
height: 32px;
|
|
|
|
|
flex: none;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider {
|
|
|
|
|
background-color: transparent;
|
|
|
|
|
width: 90px;
|
|
|
|
|
flex: 0 1 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider::-moz-range-progress {
|
|
|
|
|
background-color: black;
|
|
|
|
|
}
|
2022-07-31 03:07:44 +09:00
|
|
|
|
|
|
|
|
/*#if !MOZCENTRAL*/
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider::-webkit-slider-runnable-track,
|
|
|
|
|
/*#endif*/
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider::-moz-range-track {
|
2022-06-14 01:23:10 +09:00
|
|
|
background-color: black;
|
|
|
|
|
}
|
2022-07-31 03:07:44 +09:00
|
|
|
|
|
|
|
|
/*#if !MOZCENTRAL*/
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider::-webkit-slider-thumb,
|
|
|
|
|
/*#endif*/
|
|
|
|
|
.editorParamsToolbarContainer .editorParamsSlider::-moz-range-thumb {
|
2022-06-14 01:23:10 +09:00
|
|
|
background-color: white;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
#secondaryToolbarButtonContainer {
|
2020-07-30 01:31:58 +09:00
|
|
|
max-width: 220px;
|
2022-05-06 00:37:33 +09:00
|
|
|
min-height: 26px;
|
|
|
|
|
max-height: calc(var(--viewer-container-height) - 40px);
|
2013-09-05 06:48:31 +09:00
|
|
|
overflow-y: auto;
|
2013-09-27 18:44:45 +09:00
|
|
|
margin-bottom: -4px;
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-06-14 01:23:10 +09:00
|
|
|
#editorInkParamsToolbar {
|
|
|
|
|
inset-inline-end: 40px;
|
|
|
|
|
background-color: var(--toolbar-bg-color);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#editorFreeTextParamsToolbar {
|
|
|
|
|
inset-inline-end: 68px;
|
|
|
|
|
background-color: var(--toolbar-bg-color);
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.doorHanger,
|
|
|
|
|
.doorHangerRight {
|
2012-09-29 04:30:07 +09:00
|
|
|
border-radius: 2px;
|
2020-08-30 23:24:55 +09:00
|
|
|
box-shadow: 0 1px 5px var(--doorhanger-border-color),
|
|
|
|
|
0 0 0 1px var(--doorhanger-border-color);
|
2021-04-10 21:02:24 +09:00
|
|
|
border: var(--doorhanger-border-color-whcm);
|
2012-09-29 04:30:07 +09:00
|
|
|
}
|
2020-08-30 23:24:55 +09:00
|
|
|
.doorHanger:after,
|
|
|
|
|
.doorHanger:before,
|
|
|
|
|
.doorHangerRight:after,
|
|
|
|
|
.doorHangerRight:before {
|
2012-09-29 04:30:07 +09:00
|
|
|
bottom: 100%;
|
2022-03-14 02:30:51 +09:00
|
|
|
border: 8px solid rgba(0, 0, 0, 0);
|
2012-09-29 04:30:07 +09:00
|
|
|
content: " ";
|
|
|
|
|
height: 0;
|
|
|
|
|
width: 0;
|
|
|
|
|
position: absolute;
|
|
|
|
|
pointer-events: none;
|
2021-04-10 21:02:24 +09:00
|
|
|
opacity: var(--doorhanger-triangle-opacity-whcm);
|
2012-09-29 04:30:07 +09:00
|
|
|
}
|
2020-07-30 01:31:58 +09:00
|
|
|
.doorHanger:after {
|
2022-03-14 02:30:51 +09:00
|
|
|
inset-inline-start: 10px;
|
|
|
|
|
margin-inline-start: -8px;
|
2020-07-30 01:31:58 +09:00
|
|
|
border-bottom-color: var(--toolbar-bg-color);
|
|
|
|
|
}
|
|
|
|
|
.doorHangerRight:after {
|
2022-03-14 02:30:51 +09:00
|
|
|
inset-inline-end: 10px;
|
|
|
|
|
margin-inline-end: -8px;
|
2020-07-30 01:31:58 +09:00
|
|
|
border-bottom-color: var(--doorhanger-bg-color);
|
|
|
|
|
}
|
2013-09-05 06:48:31 +09:00
|
|
|
.doorHanger:before,
|
|
|
|
|
.doorHangerRight:before {
|
2020-07-30 01:31:58 +09:00
|
|
|
border-bottom-color: var(--doorhanger-border-color);
|
2012-09-29 04:30:07 +09:00
|
|
|
border-width: 9px;
|
2012-10-06 09:15:06 +09:00
|
|
|
}
|
2022-03-14 02:30:51 +09:00
|
|
|
.doorHanger:before {
|
|
|
|
|
inset-inline-start: 10px;
|
|
|
|
|
margin-inline-start: -9px;
|
2012-09-29 04:30:07 +09:00
|
|
|
}
|
2022-03-14 02:30:51 +09:00
|
|
|
.doorHangerRight:before {
|
|
|
|
|
inset-inline-end: 10px;
|
|
|
|
|
margin-inline-end: -9px;
|
2012-10-06 09:15:06 +09:00
|
|
|
}
|
|
|
|
|
|
2014-07-16 23:39:34 +09:00
|
|
|
#findResultsCount {
|
2019-12-25 21:28:04 +09:00
|
|
|
background-color: rgba(217, 217, 217, 1);
|
|
|
|
|
color: rgba(82, 82, 82, 1);
|
2014-07-16 23:39:34 +09:00
|
|
|
text-align: center;
|
2021-04-10 21:02:24 +09:00
|
|
|
padding: 4px 5px;
|
2020-07-30 01:31:58 +09:00
|
|
|
margin: 5px;
|
2014-07-16 23:39:34 +09:00
|
|
|
}
|
|
|
|
|
|
2012-09-29 03:18:45 +09:00
|
|
|
#findMsg {
|
2020-07-30 01:31:58 +09:00
|
|
|
color: rgba(251, 0, 0, 1);
|
2012-09-12 01:30:44 +09:00
|
|
|
}
|
2022-02-04 06:16:56 +09:00
|
|
|
|
|
|
|
|
#findResultsCount:empty,
|
2017-03-09 07:54:28 +09:00
|
|
|
#findMsg:empty {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
2012-09-12 01:30:44 +09:00
|
|
|
|
2016-11-04 00:56:57 +09:00
|
|
|
#toolbarViewerMiddle {
|
|
|
|
|
position: absolute;
|
|
|
|
|
left: 50%;
|
|
|
|
|
transform: translateX(-50%);
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-14 07:21:32 +09:00
|
|
|
#toolbarViewerLeft,
|
|
|
|
|
#toolbarSidebarLeft {
|
|
|
|
|
float: inline-start;
|
2012-04-26 03:34:28 +09:00
|
|
|
}
|
2022-03-14 07:21:32 +09:00
|
|
|
#toolbarViewerRight,
|
|
|
|
|
#toolbarSidebarRight {
|
|
|
|
|
float: inline-end;
|
2012-04-26 03:34:28 +09:00
|
|
|
}
|
2022-03-14 07:21:32 +09:00
|
|
|
|
|
|
|
|
#toolbarViewerLeft > *,
|
|
|
|
|
#toolbarViewerMiddle > *,
|
|
|
|
|
#toolbarViewerRight > *,
|
|
|
|
|
#toolbarSidebarLeft *,
|
|
|
|
|
#toolbarSidebarRight *,
|
|
|
|
|
.findbar * {
|
2013-04-04 00:31:58 +09:00
|
|
|
position: relative;
|
2022-03-14 07:21:32 +09:00
|
|
|
float: inline-start;
|
2012-02-07 17:23:23 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-22 20:04:12 +09:00
|
|
|
#toolbarViewerLeft {
|
|
|
|
|
padding-inline-start: 1px;
|
|
|
|
|
}
|
|
|
|
|
#toolbarViewerRight {
|
|
|
|
|
padding-inline-end: 1px;
|
|
|
|
|
}
|
|
|
|
|
#toolbarSidebarRight {
|
|
|
|
|
padding-inline-end: 2px;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-03 22:42:40 +09:00
|
|
|
.splitToolbarButton {
|
2022-04-22 20:04:12 +09:00
|
|
|
margin: 2px;
|
2012-05-02 07:08:30 +09:00
|
|
|
display: inline-block;
|
|
|
|
|
}
|
2022-03-14 07:21:32 +09:00
|
|
|
.splitToolbarButton > .toolbarButton {
|
|
|
|
|
float: inline-start;
|
2012-02-05 05:13:12 +09:00
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.toolbarButton,
|
2014-05-12 22:50:13 +09:00
|
|
|
.secondaryToolbarButton,
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton {
|
2012-04-26 03:34:28 +09:00
|
|
|
border: 0 none;
|
2014-05-19 00:32:26 +09:00
|
|
|
background: none;
|
2020-07-30 01:31:58 +09:00
|
|
|
width: 28px;
|
|
|
|
|
height: 28px;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton:hover,
|
|
|
|
|
.dialogButton:focus-visible {
|
|
|
|
|
background-color: var(--dialog-button-hover-bg-color);
|
2021-04-10 21:02:24 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton:hover > span,
|
|
|
|
|
.dialogButton:focus-visible > span {
|
|
|
|
|
color: var(--dialog-button-hover-color);
|
2012-02-05 05:13:12 +09:00
|
|
|
}
|
|
|
|
|
|
2012-05-04 23:51:21 +09:00
|
|
|
.toolbarButton > span {
|
2012-05-05 02:34:18 +09:00
|
|
|
display: inline-block;
|
|
|
|
|
width: 0;
|
|
|
|
|
height: 0;
|
2011-07-29 02:48:05 +09:00
|
|
|
overflow: hidden;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.toolbarButton[disabled],
|
2014-05-12 22:50:13 +09:00
|
|
|
.secondaryToolbarButton[disabled],
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton[disabled] {
|
2020-08-30 23:24:55 +09:00
|
|
|
opacity: 0.5;
|
2012-04-26 08:48:01 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.splitToolbarButton > .toolbarButton:hover,
|
2022-01-31 00:10:32 +09:00
|
|
|
.splitToolbarButton > .toolbarButton:focus-visible,
|
2022-04-25 21:46:10 +09:00
|
|
|
.dropdownToolbarButton:hover {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--button-hover-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
}
|
2014-03-19 05:32:47 +09:00
|
|
|
.splitToolbarButton > .toolbarButton {
|
|
|
|
|
position: relative;
|
2012-04-12 08:12:51 +09:00
|
|
|
margin: 0;
|
|
|
|
|
}
|
2022-04-22 20:04:12 +09:00
|
|
|
#toolbarSidebar .splitToolbarButton > .toolbarButton {
|
|
|
|
|
margin-inline-end: 2px;
|
|
|
|
|
}
|
2022-03-17 19:18:47 +09:00
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.splitToolbarButtonSeparator {
|
2022-03-14 07:21:32 +09:00
|
|
|
float: inline-start;
|
2022-04-25 21:15:59 +09:00
|
|
|
margin: 4px 0;
|
2012-04-12 08:12:51 +09:00
|
|
|
width: 1px;
|
2022-04-25 21:15:59 +09:00
|
|
|
height: 20px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--separator-color);
|
2012-05-02 07:08:30 +09:00
|
|
|
}
|
2020-07-30 01:31:58 +09:00
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarButton,
|
2013-09-05 06:48:31 +09:00
|
|
|
.dropdownToolbarButton,
|
2014-05-12 22:50:13 +09:00
|
|
|
.secondaryToolbarButton,
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton {
|
2012-04-12 08:12:51 +09:00
|
|
|
min-width: 16px;
|
2021-01-03 22:42:40 +09:00
|
|
|
margin: 2px 1px;
|
2012-04-27 06:38:41 +09:00
|
|
|
padding: 2px 6px 0;
|
2020-07-30 01:31:58 +09:00
|
|
|
border: none;
|
2012-04-12 08:12:51 +09:00
|
|
|
border-radius: 2px;
|
2020-07-30 01:31:58 +09:00
|
|
|
color: var(--main-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
font-size: 12px;
|
|
|
|
|
line-height: 14px;
|
2018-04-04 07:18:57 +09:00
|
|
|
user-select: none;
|
2012-04-12 08:12:51 +09:00
|
|
|
cursor: default;
|
2020-07-30 01:31:58 +09:00
|
|
|
box-sizing: border-box;
|
2012-04-12 08:12:51 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.toolbarButton:hover,
|
2022-01-31 00:10:32 +09:00
|
|
|
.toolbarButton:focus-visible {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--button-hover-color);
|
|
|
|
|
}
|
2013-09-05 06:48:31 +09:00
|
|
|
.secondaryToolbarButton:hover,
|
2022-01-31 00:10:32 +09:00
|
|
|
.secondaryToolbarButton:focus-visible {
|
2021-04-10 21:02:24 +09:00
|
|
|
background-color: var(--doorhanger-hover-bg-color);
|
|
|
|
|
color: var(--doorhanger-hover-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.toolbarButton.toggled,
|
2013-09-05 06:48:31 +09:00
|
|
|
.splitToolbarButton.toggled > .toolbarButton.toggled,
|
|
|
|
|
.secondaryToolbarButton.toggled {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--toggled-btn-bg-color);
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--toggled-btn-color);
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-21 22:40:38 +09:00
|
|
|
.toolbarButton.toggled::before,
|
2021-04-10 21:02:24 +09:00
|
|
|
.secondaryToolbarButton.toggled::before {
|
|
|
|
|
background-color: var(--toggled-btn-color);
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarButton.toggled:hover:active,
|
2013-09-05 06:48:31 +09:00
|
|
|
.splitToolbarButton.toggled > .toolbarButton.toggled:hover:active,
|
|
|
|
|
.secondaryToolbarButton.toggled:hover:active {
|
2021-01-03 22:42:40 +09:00
|
|
|
background-color: var(--toggled-hover-active-btn-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.dropdownToolbarButton {
|
2021-09-15 22:00:56 +09:00
|
|
|
width: var(--scale-select-container-width);
|
2015-06-04 04:03:10 +09:00
|
|
|
padding: 0;
|
2011-09-22 07:32:36 +09:00
|
|
|
overflow: hidden;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--dropdown-btn-bg-color);
|
2012-05-02 07:08:30 +09:00
|
|
|
}
|
2020-03-04 23:56:08 +09:00
|
|
|
.dropdownToolbarButton::after {
|
2020-07-30 01:31:58 +09:00
|
|
|
top: 6px;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-end: 7px;
|
2020-07-30 01:31:58 +09:00
|
|
|
pointer-events: none;
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-menuArrow-icon);
|
2012-05-02 07:08:30 +09:00
|
|
|
}
|
2011-08-31 21:22:48 +09:00
|
|
|
|
2012-04-18 03:10:52 +09:00
|
|
|
.dropdownToolbarButton > select {
|
2021-09-15 22:00:56 +09:00
|
|
|
width: calc(
|
|
|
|
|
var(--scale-select-container-width) + var(--scale-select-overflow)
|
|
|
|
|
);
|
2020-07-30 01:31:58 +09:00
|
|
|
height: 28px;
|
2012-04-14 03:13:53 +09:00
|
|
|
font-size: 12px;
|
2020-07-30 01:31:58 +09:00
|
|
|
color: var(--main-color);
|
2013-02-27 05:06:53 +09:00
|
|
|
margin: 0;
|
2020-08-20 16:36:35 +09:00
|
|
|
padding: 1px 0 2px;
|
2022-03-13 22:36:11 +09:00
|
|
|
padding-inline-start: 4px;
|
2013-02-27 05:06:53 +09:00
|
|
|
border: none;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--dropdown-btn-bg-color);
|
|
|
|
|
}
|
2021-04-10 21:02:24 +09:00
|
|
|
.dropdownToolbarButton > select:hover,
|
2022-01-31 00:10:32 +09:00
|
|
|
.dropdownToolbarButton > select:focus-visible {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--button-hover-color);
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--toggled-btn-color);
|
2012-02-07 17:23:23 +09:00
|
|
|
}
|
2012-05-17 10:19:38 +09:00
|
|
|
.dropdownToolbarButton > select > option {
|
2020-07-30 01:31:58 +09:00
|
|
|
background: var(--doorhanger-bg-color);
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--main-color);
|
2012-05-17 10:19:38 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarButtonSpacer {
|
|
|
|
|
width: 30px;
|
2011-08-31 21:22:48 +09:00
|
|
|
display: inline-block;
|
2012-04-26 03:34:28 +09:00
|
|
|
height: 1px;
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.toolbarButton::before,
|
2020-11-29 23:32:15 +09:00
|
|
|
.secondaryToolbarButton::before,
|
2020-12-02 19:48:32 +09:00
|
|
|
.dropdownToolbarButton::after,
|
|
|
|
|
.treeItemToggler::before {
|
2013-04-04 00:31:58 +09:00
|
|
|
/* All matching images have a size of 16x16
|
2020-07-30 01:31:58 +09:00
|
|
|
* All relevant containers have a size of 28x28 */
|
2013-04-04 00:31:58 +09:00
|
|
|
position: absolute;
|
2013-09-05 06:48:31 +09:00
|
|
|
display: inline-block;
|
2020-11-29 23:32:15 +09:00
|
|
|
width: 16px;
|
|
|
|
|
height: 16px;
|
|
|
|
|
|
|
|
|
|
content: "";
|
|
|
|
|
background-color: var(--toolbar-icon-bg-color);
|
|
|
|
|
mask-size: cover;
|
|
|
|
|
}
|
2021-01-03 22:42:40 +09:00
|
|
|
|
2021-04-10 21:02:24 +09:00
|
|
|
.dropdownToolbarButton:hover::after,
|
2022-01-31 00:10:32 +09:00
|
|
|
.dropdownToolbarButton:focus-visible::after,
|
2021-04-10 21:02:24 +09:00
|
|
|
.dropdownToolbarButton:active::after {
|
|
|
|
|
background-color: var(--toolbar-icon-hover-bg-color);
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-03 22:42:40 +09:00
|
|
|
.toolbarButton::before {
|
|
|
|
|
opacity: var(--toolbar-icon-opacity);
|
|
|
|
|
top: 6px;
|
2020-07-30 01:31:58 +09:00
|
|
|
left: 6px;
|
2013-04-04 00:31:58 +09:00
|
|
|
}
|
2013-09-15 02:33:00 +09:00
|
|
|
|
2021-04-10 21:02:24 +09:00
|
|
|
.toolbarButton:hover::before,
|
2022-01-31 00:10:32 +09:00
|
|
|
.toolbarButton:focus-visible::before,
|
2021-04-10 21:02:24 +09:00
|
|
|
.secondaryToolbarButton:hover::before,
|
2022-01-31 00:10:32 +09:00
|
|
|
.secondaryToolbarButton:focus-visible::before {
|
2021-04-10 21:02:24 +09:00
|
|
|
background-color: var(--toolbar-icon-hover-bg-color);
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-03 22:42:40 +09:00
|
|
|
.secondaryToolbarButton::before {
|
|
|
|
|
opacity: var(--doorhanger-icon-opacity);
|
|
|
|
|
top: 5px;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-start: 12px;
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#sidebarToggle::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-sidebarToggle-icon);
|
2022-03-20 00:56:47 +09:00
|
|
|
transform: scaleX(var(--dir-factor));
|
2013-09-15 02:33:00 +09:00
|
|
|
}
|
2013-09-05 06:48:31 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#secondaryToolbarToggle::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-secondaryToolbarToggle-icon);
|
2022-03-20 00:56:47 +09:00
|
|
|
transform: scaleX(var(--dir-factor));
|
2013-09-15 02:33:00 +09:00
|
|
|
}
|
2013-02-23 02:52:05 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#findPrevious::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--findbarButton-previous-icon);
|
2012-10-06 09:15:06 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#findNext::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--findbarButton-next-icon);
|
2012-10-06 09:15:06 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#previous::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-pageUp-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
2012-09-13 03:05:34 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#next::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-pageDown-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
2012-05-02 09:39:24 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#zoomOut::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-zoomOut-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
2012-09-13 03:05:34 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#zoomIn::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-zoomIn-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
|
|
|
|
|
2022-09-03 23:17:22 +09:00
|
|
|
#presentationMode::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-presentationMode-icon);
|
2012-07-31 00:12:49 +09:00
|
|
|
}
|
|
|
|
|
|
2022-06-01 17:38:08 +09:00
|
|
|
#editorFreeText::before {
|
|
|
|
|
mask-image: var(--toolbarButton-editorFreeText-icon);
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-05 06:28:19 +09:00
|
|
|
#editorInk::before {
|
|
|
|
|
mask-image: var(--toolbarButton-editorInk-icon);
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#print::before,
|
|
|
|
|
#secondaryPrint::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-print-icon);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
2011-08-22 11:05:10 +09:00
|
|
|
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if GENERIC*/
|
|
|
|
|
#openFile::before,
|
|
|
|
|
#secondaryOpenFile::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-openFile-icon);
|
2012-05-21 07:12:58 +09:00
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#endif*/
|
2012-05-21 07:12:58 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#download::before,
|
|
|
|
|
#secondaryDownload::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-download-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:04:00 +09:00
|
|
|
a.secondaryToolbarButton {
|
2020-07-30 01:31:58 +09:00
|
|
|
padding-top: 6px;
|
2013-09-27 18:44:45 +09:00
|
|
|
text-decoration: none;
|
|
|
|
|
}
|
2022-04-27 23:04:00 +09:00
|
|
|
a.toolbarButton[href="#"],
|
|
|
|
|
a.secondaryToolbarButton[href="#"] {
|
2020-08-30 23:24:55 +09:00
|
|
|
opacity: 0.5;
|
2013-03-19 07:53:45 +09:00
|
|
|
pointer-events: none;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-03 23:17:22 +09:00
|
|
|
#viewBookmark::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-bookmark-icon);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
2012-09-13 03:05:34 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#viewThumbnail::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-viewThumbnail-icon);
|
2012-04-12 08:12:51 +09:00
|
|
|
}
|
2012-09-13 03:05:34 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#viewOutline::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-viewOutline-icon);
|
2022-03-20 00:56:47 +09:00
|
|
|
transform: scaleX(var(--dir-factor));
|
2013-09-15 02:33:00 +09:00
|
|
|
}
|
2011-08-22 11:05:10 +09:00
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#viewAttachments::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-viewAttachments-icon);
|
2014-03-19 05:32:47 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#viewLayers::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-viewLayers-icon);
|
[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
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#currentOutlineItem::before {
|
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
|
|
|
mask-image: var(--toolbarButton-currentOutlineItem-icon);
|
2022-03-20 00:56:47 +09:00
|
|
|
transform: scaleX(var(--dir-factor));
|
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
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#viewFind::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--toolbarButton-search-icon);
|
2012-05-09 06:22:48 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
.pdfSidebarNotification::after {
|
2017-01-15 20:37:06 +09:00
|
|
|
position: absolute;
|
|
|
|
|
display: inline-block;
|
|
|
|
|
top: 1px;
|
2022-03-17 19:18:47 +09:00
|
|
|
inset-inline-start: 17px;
|
2017-01-15 20:37:06 +09:00
|
|
|
/* Create a filled circle, with a diameter of 9 pixels, using only CSS: */
|
2020-08-30 23:24:55 +09:00
|
|
|
content: "";
|
2019-12-26 00:19:14 +09:00
|
|
|
background-color: rgba(112, 219, 85, 1);
|
2017-01-15 20:37:06 +09:00
|
|
|
height: 9px;
|
|
|
|
|
width: 9px;
|
|
|
|
|
border-radius: 50%;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.secondaryToolbarButton {
|
|
|
|
|
position: relative;
|
2020-07-30 01:31:58 +09:00
|
|
|
margin: 0;
|
2021-01-22 22:36:02 +09:00
|
|
|
padding: 0 0 1px;
|
2022-03-13 22:36:11 +09:00
|
|
|
padding-inline-start: 36px;
|
2013-09-05 06:48:31 +09:00
|
|
|
height: auto;
|
2020-07-30 01:31:58 +09:00
|
|
|
min-height: 26px;
|
2013-09-05 06:48:31 +09:00
|
|
|
width: auto;
|
|
|
|
|
min-width: 100%;
|
2022-03-13 22:36:11 +09:00
|
|
|
text-align: start;
|
2013-09-05 06:48:31 +09:00
|
|
|
white-space: normal;
|
2020-07-30 01:31:58 +09:00
|
|
|
border-radius: 0;
|
|
|
|
|
box-sizing: border-box;
|
2022-09-08 05:40:00 +09:00
|
|
|
display: inline-block;
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
2022-03-13 22:36:11 +09:00
|
|
|
.secondaryToolbarButton > span {
|
|
|
|
|
padding-inline-end: 4px;
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#firstPage::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-firstPage-icon);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#lastPage::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-lastPage-icon);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#pageRotateCcw::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-rotateCcw-icon);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#pageRotateCw::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-rotateCw-icon);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#cursorSelectTool::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-selectTool-icon);
|
2016-09-07 20:30:26 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#cursorHandTool::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-handTool-icon);
|
2013-10-03 05:09:43 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#scrollPage::before {
|
2021-10-07 21:04:41 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-scrollPage-icon);
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#scrollVertical::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-scrollVertical-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#scrollHorizontal::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-scrollHorizontal-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#scrollWrapped::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-scrollWrapped-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#spreadNone::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-spreadNone-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#spreadOdd::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-spreadOdd-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#spreadEven::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-spreadEven-icon);
|
2018-05-15 12:10:32 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#documentProperties::before {
|
2020-11-29 23:32:15 +09:00
|
|
|
mask-image: var(--secondaryToolbarButton-documentProperties-icon);
|
2014-01-22 08:07:07 +09:00
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.verticalToolbarSeparator {
|
|
|
|
|
display: block;
|
2020-07-30 01:31:58 +09:00
|
|
|
margin: 5px 2px;
|
2013-09-05 06:48:31 +09:00
|
|
|
width: 1px;
|
2022-04-25 21:15:59 +09:00
|
|
|
height: 22px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--separator-color);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
.horizontalToolbarSeparator {
|
2014-08-19 04:56:15 +09:00
|
|
|
display: block;
|
2022-04-25 21:15:59 +09:00
|
|
|
margin: 6px 0;
|
2013-09-05 06:48:31 +09:00
|
|
|
height: 1px;
|
|
|
|
|
width: 100%;
|
2022-04-25 21:15:59 +09:00
|
|
|
background-color: var(--doorhanger-separator-color);
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
2012-05-09 06:22:48 +09:00
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarField {
|
2020-07-30 01:31:58 +09:00
|
|
|
padding: 4px 7px;
|
2021-01-22 22:36:02 +09:00
|
|
|
margin: 3px 0;
|
2012-04-12 08:12:51 +09:00
|
|
|
border-radius: 2px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--field-bg-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
background-clip: padding-box;
|
2022-04-27 23:04:00 +09:00
|
|
|
border: 1px solid var(--field-border-color);
|
2020-07-30 01:31:58 +09:00
|
|
|
box-shadow: none;
|
|
|
|
|
color: var(--field-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
font-size: 12px;
|
2020-07-30 01:31:58 +09:00
|
|
|
line-height: 16px;
|
2012-04-12 08:12:51 +09:00
|
|
|
outline-style: none;
|
2011-08-29 05:10:14 +09:00
|
|
|
}
|
|
|
|
|
|
2020-08-30 23:24:55 +09:00
|
|
|
.toolbarField[type="checkbox"] {
|
2020-07-30 01:31:58 +09:00
|
|
|
opacity: 0;
|
|
|
|
|
position: absolute !important;
|
|
|
|
|
left: 0;
|
2022-03-14 02:30:51 +09:00
|
|
|
margin: 10px 0 3px;
|
|
|
|
|
margin-inline-start: 7px;
|
2012-10-06 09:15:06 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-27 23:13:26 +09:00
|
|
|
#pageNumber {
|
2013-12-11 00:15:22 +09:00
|
|
|
-moz-appearance: textfield; /* hides the spinner in moz */
|
2012-06-08 05:51:29 +09:00
|
|
|
text-align: right;
|
2012-04-26 03:21:10 +09:00
|
|
|
width: 40px;
|
2012-04-26 00:32:37 +09:00
|
|
|
}
|
2022-04-27 23:13:26 +09:00
|
|
|
#pageNumber.visiblePageIsLoading {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-image: var(--loading-icon);
|
2014-07-18 20:53:04 +09:00
|
|
|
background-repeat: no-repeat;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-position: 3px;
|
2014-07-18 20:53:04 +09:00
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if !MOZCENTRAL*/
|
2022-04-27 23:13:26 +09:00
|
|
|
#pageNumber::-webkit-inner-spin-button {
|
2020-07-30 01:31:58 +09:00
|
|
|
-webkit-appearance: none;
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#endif*/
|
2011-08-22 11:05:10 +09:00
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarField:focus {
|
2020-07-30 01:31:58 +09:00
|
|
|
border-color: #0a84ff;
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.toolbarLabel {
|
|
|
|
|
min-width: 16px;
|
2021-04-10 21:02:24 +09:00
|
|
|
padding: 7px;
|
2020-07-30 01:31:58 +09:00
|
|
|
margin: 2px;
|
2012-04-12 08:12:51 +09:00
|
|
|
border-radius: 2px;
|
2020-07-30 01:31:58 +09:00
|
|
|
color: var(--main-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
font-size: 12px;
|
|
|
|
|
line-height: 14px;
|
|
|
|
|
text-align: left;
|
2018-04-04 07:18:57 +09:00
|
|
|
user-select: none;
|
2012-04-12 08:12:51 +09:00
|
|
|
cursor: default;
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-13 22:36:11 +09:00
|
|
|
#numPages.toolbarLabel {
|
|
|
|
|
padding-inline-start: 3px;
|
2020-08-23 23:21:07 +09:00
|
|
|
}
|
|
|
|
|
|
2022-04-12 20:47:13 +09:00
|
|
|
#thumbnailView,
|
|
|
|
|
#outlineView,
|
|
|
|
|
#attachmentsView,
|
|
|
|
|
#layersView {
|
2012-09-06 00:31:23 +09:00
|
|
|
position: absolute;
|
2022-04-12 20:47:13 +09:00
|
|
|
width: calc(100% - 8px);
|
2012-09-06 00:31:23 +09:00
|
|
|
top: 0;
|
2012-04-13 07:13:58 +09:00
|
|
|
bottom: 0;
|
2022-04-12 20:47:13 +09:00
|
|
|
padding: 4px 4px 0;
|
2011-08-22 11:05:10 +09:00
|
|
|
overflow: auto;
|
2022-04-12 20:47:13 +09:00
|
|
|
user-select: none;
|
|
|
|
|
}
|
|
|
|
|
#thumbnailView {
|
|
|
|
|
width: calc(100% - 60px);
|
|
|
|
|
padding: 10px 30px 0;
|
2011-10-29 01:16:17 +09:00
|
|
|
}
|
|
|
|
|
|
2018-12-19 06:48:26 +09:00
|
|
|
#thumbnailView > a:active,
|
|
|
|
|
#thumbnailView > a:focus {
|
|
|
|
|
outline: 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.thumbnail {
|
2022-03-14 07:21:32 +09:00
|
|
|
float: inline-start;
|
2021-01-22 22:36:02 +09:00
|
|
|
margin: 0 10px 5px;
|
2013-10-10 03:40:21 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#thumbnailView > a:last-of-type > .thumbnail {
|
|
|
|
|
margin-bottom: 10px;
|
2012-04-14 06:14:05 +09:00
|
|
|
}
|
2014-12-30 23:05:39 +09:00
|
|
|
#thumbnailView > a:last-of-type > .thumbnail:not([data-loaded]) {
|
|
|
|
|
margin-bottom: 9px;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-26 03:34:28 +09:00
|
|
|
.thumbnail:not([data-loaded]) {
|
2020-07-30 01:31:58 +09:00
|
|
|
border: 1px dashed rgba(132, 132, 132, 1);
|
2021-01-22 22:36:02 +09:00
|
|
|
margin: -1px 9px 4px;
|
2012-04-14 06:14:05 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.thumbnailImage {
|
2019-12-25 22:44:05 +09:00
|
|
|
border: 1px solid rgba(0, 0, 0, 0);
|
2012-04-14 06:14:05 +09:00
|
|
|
box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.5), 0 2px 8px rgba(0, 0, 0, 0.3);
|
|
|
|
|
opacity: 0.8;
|
|
|
|
|
z-index: 99;
|
2019-12-25 22:44:05 +09:00
|
|
|
background-color: rgba(255, 255, 255, 1);
|
2015-01-20 05:39:38 +09:00
|
|
|
background-clip: content-box;
|
2011-12-22 07:22:07 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.thumbnailSelectionRing {
|
|
|
|
|
border-radius: 2px;
|
2012-04-14 06:14:05 +09:00
|
|
|
padding: 7px;
|
2011-12-22 07:22:07 +09:00
|
|
|
}
|
2012-09-13 03:05:34 +09:00
|
|
|
|
2012-05-02 01:43:48 +09:00
|
|
|
a:focus > .thumbnail > .thumbnailSelectionRing > .thumbnailImage,
|
2012-04-14 06:14:05 +09:00
|
|
|
.thumbnail:hover > .thumbnailSelectionRing > .thumbnailImage {
|
2020-08-30 23:24:55 +09:00
|
|
|
opacity: 0.9;
|
2011-12-22 07:22:07 +09:00
|
|
|
}
|
|
|
|
|
|
2012-05-02 01:43:48 +09:00
|
|
|
a:focus > .thumbnail > .thumbnailSelectionRing,
|
2012-04-12 08:12:51 +09:00
|
|
|
.thumbnail:hover > .thumbnailSelectionRing {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--sidebaritem-bg-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
background-clip: padding-box;
|
2019-12-25 22:15:39 +09:00
|
|
|
color: rgba(255, 255, 255, 0.9);
|
2011-12-22 07:22:07 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-14 06:14:05 +09:00
|
|
|
.thumbnail.selected > .thumbnailSelectionRing > .thumbnailImage {
|
2012-04-12 08:12:51 +09:00
|
|
|
opacity: 1;
|
2011-07-29 02:48:05 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:12:51 +09:00
|
|
|
.thumbnail.selected > .thumbnailSelectionRing {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--sidebaritem-bg-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
background-clip: padding-box;
|
2020-07-30 01:31:58 +09:00
|
|
|
color: rgba(255, 255, 255, 1);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-14 02:30:51 +09:00
|
|
|
.treeWithDeepNesting > .treeItem,
|
|
|
|
|
.treeItem > .treeItems {
|
|
|
|
|
margin-inline-start: 20px;
|
2012-12-28 21:26:30 +09:00
|
|
|
}
|
|
|
|
|
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItem > a {
|
2011-08-22 11:05:10 +09:00
|
|
|
text-decoration: none;
|
2012-06-08 05:51:29 +09:00
|
|
|
display: inline-block;
|
2020-08-29 23:35:27 +09:00
|
|
|
/* Subtract the right padding (left, in RTL mode) of the container: */
|
|
|
|
|
min-width: calc(100% - 4px);
|
2012-12-28 02:58:09 +09:00
|
|
|
height: auto;
|
2012-04-12 08:12:51 +09:00
|
|
|
margin-bottom: 1px;
|
2022-03-13 22:36:11 +09:00
|
|
|
padding: 2px 0 5px;
|
|
|
|
|
padding-inline-start: 4px;
|
2012-04-12 08:12:51 +09:00
|
|
|
border-radius: 2px;
|
2020-09-06 06:06:44 +09:00
|
|
|
color: var(--treeitem-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
font-size: 13px;
|
|
|
|
|
line-height: 15px;
|
2018-04-04 07:18:57 +09:00
|
|
|
user-select: none;
|
2012-12-28 02:58:09 +09:00
|
|
|
white-space: normal;
|
2014-04-26 05:42:19 +09:00
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
2012-12-28 21:26:30 +09:00
|
|
|
|
2022-06-25 03:12:50 +09:00
|
|
|
#layersView .treeItem > a * {
|
[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
|
|
|
cursor: pointer;
|
|
|
|
|
}
|
2022-03-13 22:36:11 +09:00
|
|
|
#layersView .treeItem > a > label {
|
|
|
|
|
padding-inline-start: 4px;
|
[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
|
|
|
}
|
2022-06-25 03:12:50 +09:00
|
|
|
#layersView .treeItem > a > label > input {
|
|
|
|
|
float: inline-start;
|
|
|
|
|
margin-top: 1px;
|
|
|
|
|
}
|
[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
|
|
|
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItemToggler {
|
2015-07-22 02:52:49 +09:00
|
|
|
position: relative;
|
2022-03-14 07:21:32 +09:00
|
|
|
float: inline-start;
|
2015-07-22 02:52:49 +09:00
|
|
|
height: 0;
|
|
|
|
|
width: 0;
|
2019-12-25 22:15:39 +09:00
|
|
|
color: rgba(255, 255, 255, 0.5);
|
2015-07-22 02:52:49 +09:00
|
|
|
}
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItemToggler::before {
|
2022-03-14 07:21:32 +09:00
|
|
|
inset-inline-end: 4px;
|
2020-12-02 19:48:32 +09:00
|
|
|
mask-image: var(--treeitem-expanded-icon);
|
2015-07-22 02:52:49 +09:00
|
|
|
}
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItemToggler.treeItemsHidden::before {
|
2020-12-02 19:48:32 +09:00
|
|
|
mask-image: var(--treeitem-collapsed-icon);
|
2022-03-20 00:56:47 +09:00
|
|
|
transform: scaleX(var(--dir-factor));
|
2015-09-06 22:34:02 +09:00
|
|
|
}
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItemToggler.treeItemsHidden ~ .treeItems {
|
2015-07-22 02:52:49 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
.treeItem.selected > a {
|
|
|
|
|
background-color: var(--treeitem-selected-bg-color);
|
|
|
|
|
color: var(--treeitem-selected-color);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-04 19:40:59 +09:00
|
|
|
.treeItemToggler:hover,
|
|
|
|
|
.treeItemToggler:hover + a,
|
|
|
|
|
.treeItemToggler:hover ~ .treeItems,
|
|
|
|
|
.treeItem > a:hover {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--sidebaritem-bg-color);
|
2012-04-12 08:12:51 +09:00
|
|
|
background-clip: padding-box;
|
2015-09-03 22:22:48 +09:00
|
|
|
border-radius: 2px;
|
2020-09-06 06:06:44 +09:00
|
|
|
color: var(--treeitem-hover-color);
|
2011-08-22 11:05:10 +09:00
|
|
|
}
|
|
|
|
|
|
2012-04-13 09:57:52 +09:00
|
|
|
/* TODO: file FF bug to support ::-moz-selection:window-inactive
|
|
|
|
|
so we can override the opaque grey background when the window is inactive;
|
|
|
|
|
see https://bugzilla.mozilla.org/show_bug.cgi?id=706209 */
|
2019-12-25 22:23:22 +09:00
|
|
|
::selection {
|
|
|
|
|
background: rgba(0, 0, 255, 0.3);
|
|
|
|
|
}
|
2014-09-09 16:09:23 +09:00
|
|
|
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#if !MOZCENTRAL*/
|
|
|
|
|
#errorWrapper {
|
2022-04-12 19:33:51 +09:00
|
|
|
background-color: var(--errorWrapper-bg-color);
|
2020-07-30 01:31:58 +09:00
|
|
|
color: var(--main-color);
|
2011-11-29 09:55:09 +09:00
|
|
|
left: 0;
|
2012-04-26 09:20:13 +09:00
|
|
|
position: absolute;
|
2011-11-29 09:55:09 +09:00
|
|
|
right: 0;
|
|
|
|
|
z-index: 1000;
|
2020-07-30 01:31:58 +09:00
|
|
|
padding: 3px 6px;
|
2011-11-29 09:55:09 +09:00
|
|
|
}
|
|
|
|
|
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
#errorMessageLeft {
|
2011-11-29 09:55:09 +09:00
|
|
|
float: left;
|
|
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
#errorMessageRight {
|
2011-11-29 09:55:09 +09:00
|
|
|
float: right;
|
|
|
|
|
}
|
|
|
|
|
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
#errorSpacer {
|
2022-04-20 21:21:51 +09:00
|
|
|
clear: both;
|
|
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
#errorMoreInfo {
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--field-bg-color);
|
|
|
|
|
color: var(--field-color);
|
|
|
|
|
border: 1px solid var(--field-border-color);
|
2011-11-29 09:55:09 +09:00
|
|
|
padding: 3px;
|
|
|
|
|
margin: 3px;
|
2012-01-05 07:43:17 +09:00
|
|
|
width: 98%;
|
2011-11-29 09:55:09 +09:00
|
|
|
}
|
Use the regular `preprocess`-function for the CSS files as well
An old shortcoming of the `preprocessCSS`-function is its complete lack of support for our "normal" defines, which makes it very difficult to have build-specific CSS rules. Recently we've started using specially crafted comments to remove CSS rules from the MOZCENTRAL build, but (ab)using the `preprocessCSS`-function in this way really doesn't feel great.
However, it turns out to be surprisingly simple to instead use the "regular" `preprocess`-function for the CSS files as well. The only special-handling that's still necessary is the helper-function for dealing with CSS-imports, but apart from that everything seems to just work.
One reason, as far as I can tell, for having a separate `preprocessCSS`-function was likely that we originally used *lots* of vendor-prefixed CSS rules in our CSS files. With improvements over the years, especially thanks to Autoprefixer and PostCSS, we've been able to remove *almost* all non-standard CSS rules and the need for special-casing the CSS parsing has mostly vanished.
*Please note:* As part of testing this patch I've diffed the output of `gulp generic`, `gulp mozcentral`, and `gulp chromium` against the `master`-branch to check that there was no obvious breakage.
2022-05-08 05:00:54 +09:00
|
|
|
/*#endif*/
|
2011-11-29 09:55:09 +09:00
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
.dialogButton {
|
2014-05-12 22:50:13 +09:00
|
|
|
width: auto;
|
2021-01-22 22:36:02 +09:00
|
|
|
margin: 3px 4px 2px !important;
|
|
|
|
|
padding: 2px 11px;
|
2021-04-10 21:02:24 +09:00
|
|
|
color: var(--main-color);
|
2022-03-25 22:10:13 +09:00
|
|
|
background-color: var(--dialog-button-bg-color);
|
|
|
|
|
border: var(--dialog-button-border) !important;
|
2014-05-12 22:50:13 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog {
|
|
|
|
|
margin: auto;
|
2013-09-25 00:46:54 +09:00
|
|
|
padding: 15px;
|
|
|
|
|
border-spacing: 4px;
|
2020-07-30 01:31:58 +09:00
|
|
|
color: var(--main-color);
|
2014-05-12 22:50:13 +09:00
|
|
|
font-size: 12px;
|
2013-09-25 00:46:54 +09:00
|
|
|
line-height: 14px;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--doorhanger-bg-color);
|
2019-12-25 22:15:39 +09:00
|
|
|
border: 1px solid rgba(0, 0, 0, 0.5);
|
2014-05-12 22:50:13 +09:00
|
|
|
border-radius: 4px;
|
|
|
|
|
box-shadow: 0 1px 4px rgba(0, 0, 0, 0.3);
|
2013-09-25 00:46:54 +09:00
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog::backdrop {
|
|
|
|
|
background-color: rgba(0, 0, 0, 0.2);
|
|
|
|
|
}
|
2013-09-25 00:46:54 +09:00
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog > .row {
|
2013-09-25 00:46:54 +09:00
|
|
|
display: table-row;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog > .row > * {
|
2013-09-25 00:46:54 +09:00
|
|
|
display: table-cell;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog .toolbarField {
|
2013-09-25 00:46:54 +09:00
|
|
|
margin: 5px 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog .separator {
|
2014-08-19 04:56:15 +09:00
|
|
|
display: block;
|
2021-01-22 22:36:02 +09:00
|
|
|
margin: 4px 0;
|
2014-01-22 08:07:07 +09:00
|
|
|
height: 1px;
|
|
|
|
|
width: 100%;
|
2020-07-30 01:31:58 +09:00
|
|
|
background-color: var(--separator-color);
|
2014-01-22 08:07:07 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog .buttonRow {
|
2014-05-12 22:50:13 +09:00
|
|
|
text-align: center;
|
|
|
|
|
vertical-align: middle;
|
2014-01-22 08:07:07 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
dialog :link {
|
2019-12-25 22:44:05 +09:00
|
|
|
color: rgba(255, 255, 255, 1);
|
2015-07-19 00:11:33 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
#passwordDialog {
|
2014-05-12 22:50:13 +09:00
|
|
|
text-align: center;
|
|
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
#passwordDialog .toolbarField {
|
2014-05-12 22:50:13 +09:00
|
|
|
width: 200px;
|
2014-01-22 08:07:07 +09:00
|
|
|
}
|
|
|
|
|
|
2022-03-25 22:10:13 +09:00
|
|
|
#documentPropertiesDialog {
|
2014-05-12 22:50:13 +09:00
|
|
|
text-align: left;
|
|
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
#documentPropertiesDialog .row > * {
|
2014-01-22 08:07:07 +09:00
|
|
|
min-width: 100px;
|
2022-03-13 22:36:11 +09:00
|
|
|
text-align: start;
|
2014-01-22 08:07:07 +09:00
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
#documentPropertiesDialog .row > span {
|
2014-01-23 08:30:48 +09:00
|
|
|
width: 125px;
|
|
|
|
|
word-wrap: break-word;
|
|
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
#documentPropertiesDialog .row > p {
|
2014-01-23 08:30:48 +09:00
|
|
|
max-width: 225px;
|
|
|
|
|
word-wrap: break-word;
|
|
|
|
|
}
|
2022-03-25 22:10:13 +09:00
|
|
|
#documentPropertiesDialog .buttonRow {
|
2014-01-22 08:07:07 +09:00
|
|
|
margin-top: 10px;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-29 01:05:30 +09:00
|
|
|
.grab-to-pan-grab {
|
2013-12-17 03:01:59 +09:00
|
|
|
cursor: grab !important;
|
2013-10-03 05:09:43 +09:00
|
|
|
}
|
2020-08-30 23:24:55 +09:00
|
|
|
.grab-to-pan-grab
|
|
|
|
|
*:not(input):not(textarea):not(button):not(select):not(:link) {
|
2014-01-29 01:05:30 +09:00
|
|
|
cursor: inherit !important;
|
|
|
|
|
}
|
|
|
|
|
.grab-to-pan-grab:active,
|
|
|
|
|
.grab-to-pan-grabbing {
|
2013-12-17 03:01:59 +09:00
|
|
|
cursor: grabbing !important;
|
2014-01-29 01:05:30 +09:00
|
|
|
position: fixed;
|
2019-12-25 22:44:05 +09:00
|
|
|
background: rgba(0, 0, 0, 0);
|
2014-01-29 01:05:30 +09:00
|
|
|
display: block;
|
|
|
|
|
top: 0;
|
|
|
|
|
left: 0;
|
2014-01-30 23:06:04 +09:00
|
|
|
right: 0;
|
|
|
|
|
bottom: 0;
|
2014-01-29 01:05:30 +09:00
|
|
|
overflow: hidden;
|
|
|
|
|
z-index: 50000; /* should be higher than anything else in PDF.js! */
|
2013-10-03 05:09:43 +09:00
|
|
|
}
|
|
|
|
|
|
2012-06-29 01:50:25 +09:00
|
|
|
@page {
|
|
|
|
|
margin: 0;
|
2012-09-13 03:05:34 +09:00
|
|
|
}
|
2012-05-16 04:47:33 +09:00
|
|
|
|
2012-06-29 01:50:25 +09:00
|
|
|
#printContainer {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
2012-05-25 21:38:50 +09:00
|
|
|
|
2012-06-29 01:50:25 +09:00
|
|
|
@media print {
|
2013-05-01 06:39:57 +09:00
|
|
|
body {
|
2019-12-25 22:44:05 +09:00
|
|
|
background: rgba(0, 0, 0, 0) none;
|
2013-05-01 06:39:57 +09:00
|
|
|
}
|
2016-10-07 06:46:30 +09:00
|
|
|
body[data-pdfjsprinting] #outerContainer {
|
2012-07-13 02:31:20 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
2016-10-07 06:46:30 +09:00
|
|
|
body[data-pdfjsprinting] #printContainer {
|
2012-05-25 21:38:50 +09:00
|
|
|
display: block;
|
|
|
|
|
}
|
2016-02-11 06:10:03 +09:00
|
|
|
#printContainer {
|
|
|
|
|
height: 100%;
|
|
|
|
|
}
|
2015-03-19 07:15:43 +09:00
|
|
|
/* wrapper around (scaled) print canvas elements */
|
2021-05-27 23:56:31 +09:00
|
|
|
#printContainer > .printedPage {
|
2016-10-06 21:51:45 +09:00
|
|
|
page-break-after: always;
|
|
|
|
|
page-break-inside: avoid;
|
2021-03-14 23:54:37 +09:00
|
|
|
|
2021-03-26 16:51:53 +09:00
|
|
|
/* The wrapper always cover the whole page. */
|
|
|
|
|
height: 100%;
|
|
|
|
|
width: 100%;
|
|
|
|
|
|
2021-03-14 23:54:37 +09:00
|
|
|
display: flex;
|
|
|
|
|
flex-direction: column;
|
|
|
|
|
justify-content: center;
|
|
|
|
|
align-items: center;
|
2015-03-19 07:15:43 +09:00
|
|
|
}
|
2021-05-27 23:56:31 +09:00
|
|
|
|
2021-07-13 03:21:23 +09:00
|
|
|
#printContainer > .xfaPrintedPage .xfaPage {
|
2021-08-03 22:07:33 +09:00
|
|
|
position: absolute;
|
2021-07-13 03:21:23 +09:00
|
|
|
}
|
|
|
|
|
|
2021-05-27 23:56:31 +09:00
|
|
|
#printContainer > .xfaPrintedPage {
|
|
|
|
|
page-break-after: always;
|
|
|
|
|
page-break-inside: avoid;
|
|
|
|
|
width: 100%;
|
|
|
|
|
height: 100%;
|
|
|
|
|
position: relative;
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-03 04:37:49 +09:00
|
|
|
#printContainer > .printedPage canvas,
|
|
|
|
|
#printContainer > .printedPage img {
|
2021-03-26 16:51:53 +09:00
|
|
|
/* The intrinsic canvas / image size will make sure that we fit the page. */
|
|
|
|
|
max-width: 100%;
|
|
|
|
|
max-height: 100%;
|
|
|
|
|
|
2020-08-11 01:31:07 +09:00
|
|
|
direction: ltr;
|
2014-10-01 08:01:30 +09:00
|
|
|
display: block;
|
2012-06-29 01:50:25 +09:00
|
|
|
}
|
2012-05-25 21:38:50 +09:00
|
|
|
}
|
|
|
|
|
|
2013-09-05 06:48:31 +09:00
|
|
|
.visibleLargeView,
|
2022-09-08 05:40:00 +09:00
|
|
|
.visibleMediumView {
|
2013-09-05 06:48:31 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-04 00:56:57 +09:00
|
|
|
@media all and (max-width: 900px) {
|
|
|
|
|
#toolbarViewerMiddle {
|
|
|
|
|
display: table;
|
|
|
|
|
margin: auto;
|
|
|
|
|
left: auto;
|
|
|
|
|
position: inherit;
|
|
|
|
|
transform: none;
|
|
|
|
|
}
|
2012-05-22 00:59:43 +09:00
|
|
|
}
|
2012-05-16 04:47:33 +09:00
|
|
|
|
2016-11-04 00:56:57 +09:00
|
|
|
@media all and (max-width: 840px) {
|
2021-03-02 02:27:27 +09:00
|
|
|
#sidebarContainer {
|
|
|
|
|
background-color: var(--sidebar-narrow-bg-color);
|
2012-05-16 04:47:33 +09:00
|
|
|
}
|
2022-03-17 19:18:47 +09:00
|
|
|
#outerContainer.sidebarOpen #viewerContainer {
|
|
|
|
|
inset-inline-start: 0 !important;
|
2012-05-16 04:47:33 +09:00
|
|
|
}
|
2013-09-05 06:48:31 +09:00
|
|
|
}
|
|
|
|
|
|
2022-07-01 20:27:13 +09:00
|
|
|
@media all and (max-width: 820px) {
|
2013-09-05 06:48:31 +09:00
|
|
|
#outerContainer .hiddenLargeView {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
#outerContainer .visibleLargeView {
|
|
|
|
|
display: inherit;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-01 20:27:13 +09:00
|
|
|
@media all and (max-width: 750px) {
|
2013-09-05 06:48:31 +09:00
|
|
|
#outerContainer .hiddenMediumView {
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
#outerContainer .visibleMediumView {
|
|
|
|
|
display: inherit;
|
2012-05-16 04:47:33 +09:00
|
|
|
}
|
|
|
|
|
}
|
2012-05-22 03:08:42 +09:00
|
|
|
|
2022-07-01 20:27:13 +09:00
|
|
|
@media all and (max-width: 690px) {
|
2020-08-30 23:24:55 +09:00
|
|
|
.hiddenSmallView,
|
|
|
|
|
.hiddenSmallView * {
|
2012-05-22 03:08:42 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
2013-02-26 09:53:54 +09:00
|
|
|
.toolbarButtonSpacer {
|
|
|
|
|
width: 0;
|
|
|
|
|
}
|
2022-03-17 19:18:47 +09:00
|
|
|
.findbar {
|
|
|
|
|
inset-inline-start: 34px;
|
2017-03-09 07:54:28 +09:00
|
|
|
}
|
2012-05-22 03:08:42 +09:00
|
|
|
}
|
2012-05-24 07:10:53 +09:00
|
|
|
|
2022-07-01 20:27:13 +09:00
|
|
|
@media all and (max-width: 560px) {
|
2016-01-28 21:02:17 +09:00
|
|
|
#scaleSelectContainer {
|
2012-05-24 07:10:53 +09:00
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
}
|
