Update from upstream #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Group and scope the findbar rules using CSS nesting
There's a fair number of event listeners in the editor-code that we're currently removing "manually", by keeping references to their event handler functions. This was necessary since we have a "global" `AbortController` that applies to all event listeners used in the editor-code, however it's now possible to combine multiple `AbortSignal`s; please see https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static Since this functionality is [fairly new](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static#browser_compatibility) the viewer will check that `AbortSignal.any()` is available before enabling the editing-functionality. (It should hopefully be fairly straightforward, famous last words, for users to implement a polyfill to allow editing in older browsers.) Finally, this patch also adds checks and test-only asserts to ensure that we don't add duplicate event listeners in various editor-code.
[Editor] Change the background color of the image preview in the new alt text dialog
[Editor] Remove event listeners with `AbortSignal.any()`
…586 follow-up) Without this patch the viewer may break on load, since the check added in PR 18586 only applies to the toolbar.
…nal-any Check that `AbortSignal.any()` is supported in `PDFViewer` too (PR 18586 follow-up)
…image data to the model"
Revert "[Editor] Pass a buffer instead of a typed array when passing image data to the model"
This, ever so slightly, shortens the code for a couple of repeatedly accessed class fields.
Because of an old oversight (by me) we don't stop sidebar resizing when the browser window loses focus, which seems generally wrong and can also lead to duplicate mouse-related event listeners being registered.
This was enabled by default in Firefox 126, see [bug 1867513](https://bugzilla.mozilla.org/show_bug.cgi?id=1867513), so hopefully we should be able to remove the option/preference now.
[Editor] Add a first test to test the new alt text flow
[Firefox] Remove the "loadaiengineprogress" listener with `AbortSignal.any()`
Remove the sidebar resizing event listeners with an `AbortController`
[Editor] Add the telemetry for the new alt text (bug 1912500)
…ng CSS nesting The secondary toolbar CSS rules predate the general availability of CSS nesting, which makes them more difficult to understand and change safely. The primary issues are that the rules are spread over the `viewer.css` file, they share blocks with other elements and the scope of the rules is sometimes bigger than necessary. This refactoring groups all CSS rules for the secondary toolbar button container/icons together, scoped to the top-level `#secondaryToolbar` element, for improved overview and isolation. Note that this patch only intends to move the existing rules around and not change any behavior. Moreover, this patch does not move the rules for the secondary toolbar itself and the secondary toolbar buttons; those will be part of a follow-up patch and will be easier once this is in place first. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
…rt-1 Group and scope the secondary toolbar button container/icon rules using CSS nesting
Secondary toolbar buttons are toolbar buttons with some extra rules, mainly to make them wider and have visible labels. However, this similarity is currently not clearly reflected in the implementation because the secondary toolbar buttons use a different CSS class, `secondaryToolbarButton`, compared to the other toolbar buttons that use the `toolbarButton` CSS class. This also causes some duplication in the rules and requires extra care to keep the common bits for the `secondaryToolbarButton` class in sync with the `toolbarButton` class. Fortunately, now that we have a dedicated CSS scope for the secondary toolbar, we can simplify this by giving all secondary toolbar buttons the `toolbarButton` class and explicitly listing the required overrides in the `#secondaryToolbar` scope instead. Doing so removes most of the special-casing for secondary toolbar buttons while explicitly listing the differences in a single place for a better overview. It also lays the foundation for making all toolbar buttons respect the `browser.uidensity` Firefox preference later by reducing differences. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
…rt-2 Remove the `secondaryToolbarButton` CSS class
The secondary toolbar CSS rules predate the general availability of CSS nesting, which makes them more difficult to understand and change safely. The primary issues are that the rules are spread over the `viewer.css` file, they share blocks with other elements and the scope of the rules is sometimes bigger than necessary. This refactoring groups all remaining secondary toolbar rules together, scoped to the top-level `#secondaryToolbar` element, for improved overview and isolation. Note that this patch only intends to move the existing rules around and not change any behavior. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
We have a number of base-classes that are only intended to be extended, but never to be used directly. To help enforce this during development these base-class constructors will check for direct usage, however that code is obviously not needed in the actual builds. *Note:* This patch reduces the size of the `gulp mozcentral` output by `~2.7` kilo-bytes, which isn't a lot but still cannot hurt.
…rt-3 Group and scope the secondary toolbar rules using CSS nesting
…check Limit base-class initialization checks to development and TESTING modes
Now that we have dedicated CSS scopes for the findbar and the secondary toolbar we have ended up with two CSS blocks with identical selectors, so now we can combine them for simplicity and to remove some rules in the first block that were always overridden by the second block. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
Using the `:is(a)` selector we can move the previously separate rules into the main `.toolbarButton` override rules. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
Remove useless css variable --editor-toolbar-base-offset
Remove duplicated --toolbar-height definition in the css
…to font size (bug 1917734)
Correctly compute the font size when printing a text field with an auto font size (bug 1917734)
Increase the size of the toolbar depending on the uidensity (bug 1171799)
Add Calixte to the list of authors
Remove the unused `splitToolbarButton` CSS class (PR 18385 follow-up)
Unify separate `#toolbarContainer`-blocks in the CSS (PR 18385 follow-up)
…ent` Given that the `WorkerTransport`-constructor will access all possible factory-instances, let's ensure that the `transportFactory`-object always has a consistent shape regardless of other options. Also, since `useWorkerFetch` is always true in MOZCENTRAL builds we never need to create `CMapReaderFactory`/`StandardFontDataFactory`-instances there.
… tile dimensions (bug 1837738) It fixes #16038. The idea is to create a pattern having the steps for dimensions and then draw the base tile and the different overlapping parts on it.
Fix the rendering of tiling pattern when the steps are lower than the tile dimensions (bug 1837738)
Slightly re-factor the `transportFactory` initialization in `getDocument`
…ls (PR 15281 follow-up) This became unused in PR 15281, however that patch clearly missed some occurrences; sorry about that!
…ransform Remove `trackTransform` arguments from `CachedCanvases.getCanvas`-calls (PR 15281 follow-up)
Given the following excerpt from the [Wikipedia article](https://en.wikipedia.org/wiki/Gill_Sans), mapping this to Helvetica should hopefully be fine: > It has been described as "the British Helvetica" because of its lasting popularity in British design.
Add basic support for non-embedded GillSansMT fonts (issue 18801)
…ndary toolbar (bug 1911980)
[Editor] When deleting an annotation with popup, then delete the popup too
[Editor] Avoid to have a selected stamp annotation on top of the secondary toolbar (bug 1911980)
…(PR 15522 follow-up) We disable any non-default CursorTool in PresentationMode and during Editing, since they don't make sense there and to prevent problems such as e.g. [bug 1792422](https://bugzilla.mozilla.org/show_bug.cgi?id=1792422). Hence it seems like a good idea to *also* disable the relevant SecondaryToolbar-buttons, to avoid the user being surprised that the CursorTools-buttons do nothing if clicked.
Ensure that the CursorTools-buttons are disabled e.g. during editing (PR 15522 follow-up)
This patch updates the minimum supported browsers as follows: - Google Chrome 103[1], which was released on 2022-06-21; see https://chromereleases.googleblog.com/2022/06/stable-channel-update-for-desktop_21.html Note that nowadays we usually try, where feasible and possible, to support browsers that are about two years old. By limiting support to only "recent" browsers we reduce the risk of holding back improvements of the *built-in* Firefox PDF Viewer, and also (significantly) reduce the maintenance/support burden for the PDF.js contributors. *Please note:* As always, the minimum supported browser version assumes that a `legacy`-build of the PDF.js library is being used; see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support --- [1] This is consistent with the minimum supported version in the recently updated Google Chrome addon.
[api-minor] Update the minimum supported Google Chrome version to 103
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.