Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update from upstream #1

Merged
merged 10,000 commits into from
Oct 1, 2024
Merged

Update from upstream #1

merged 10,000 commits into from
Oct 1, 2024

Conversation

JohnAdamsy
Copy link

No description provided.

timvandermeij and others added 30 commits August 8, 2024 20:27
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)
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 <[email protected]>
…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 <[email protected]>
…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 <[email protected]>
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 <[email protected]>
Using the `:is(a)` selector we can move the previously separate rules
into the main `.toolbarButton` override rules.

Co-authored-by: Calixte Denizet <[email protected]>
calixteman and others added 29 commits September 24, 2024 10:08
Remove useless css variable --editor-toolbar-base-offset
Remove duplicated --toolbar-height definition in the css
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)
[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
@JohnAdamsy JohnAdamsy merged commit 7a3137e into Buymore:master Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants