Due to a rounding issue in gtk_paper_size_new[1], we were ending up with
a custom page size regardless, which causes issues with some printers.
Instead, use the gtk_paper_size_new_from_ipp, which is available in
almost all gtk versions we support, works nicely for our use case, has
some tolerance for minor floating point rounding issues, and should also
get a nicer codepath than the custom page size.
Before bug 1660527 we were using the printer settings, which had a paper
size created from gtk itself without parsing the ipp header, so we were
getting the happy path.
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/3685
Differential Revision: https://phabricator.services.mozilla.com/D105841
We're not 100% certain if Help is the right spot for this, but we're going
to give it a shot and see. If it turns out it _is_ the right spot, we'll
probably do something a little more self-contained, and less hacky.
I'm leaving the old .properties file just in case we change our mind here.
Yes, we'll want to port to Fluent anyways, but our ultimate choice of where
we put this thing is probably going to dictate where the string lives.
Differential Revision: https://phabricator.services.mozilla.com/D104832
This is an unusual revision, but it adds a checkbox to the Search Suggestions
section of the Search pane for the urlbar Quick Suggest experiment, which is
en-US only. The checkbox is hidden by default and it's only shown if the
`browser.urlbar.quicksuggest.enabled` pref, which controls the experiment, is
true. Because this is an experiment and it's en-US only, I've hardcoded some
strings. Bug 1692518 has info on the experiment, and bug 1693345 has a
discussion about hardcoding strings.
The checkbox controls the new pref `browser.urlbar.suggest.quicksuggest`. It's
similar to the other existing `browser.urlbar.suggest.*` prefs.
There's a learn-more link but we don't know the final URL yet, so I'm using
mozilla.org. There's a TODO with a bug number.
We also want to change the Search Suggestions description when the experiment is
enabled. I've hardcoded that new string, too.
The test is pretty thorough and I started writing it before the new prefs
landed, so it doesn't assume the prefs exist or which branch they're on.
Differential Revision: https://phabricator.services.mozilla.com/D105701
This patch enables the faster mix-blend-mode path that allows using
picture cache tiles as the backdrop source for blends where that
is appropriate (most of the underlying work is in previous patches
or the dependencies of this bug).
In addition to avoiding an extra intermediate surface for blends
that are on a picture cache surface, it also avoids constant
invalidation of picture cache tiles due to the blend container
not being part of the main content scroll root.
As an example of the typical performance improvement, the GPU times
on an AMD 5700 GPU at 4k, when using the Firelux color temperature addon
browsing pages drops from ~1.8ms to ~0.3 ms.
Differential Revision: https://phabricator.services.mozilla.com/D104491
Since MOZ_LIBAV_FFT doesn't need the flags, we simplify the libav_fft
function to return true in the conditions it used to return flags for,
which is clearer.
We then move all these flags to the ffvpx function, and rearrange the
tests to be less convoluted, and with hope, more readable.
This has been verified to not change the outcomes on the following
targets:
- i686-pc-linux-gnu
- x86_64-pc-linux-gnu
- aarch64-unknown-linux-gnu
- arm-unknown-linux-gnueabi
- s390x-unknown-linux-gnu
- i686-apple-darwin
- x86_64-apple-darwin
- aarch64-apple-darwin
- i686-pc-mingw32
- x86_64-pc-mingw32
- aarch64-pc-mingw32
Differential Revision: https://phabricator.services.mozilla.com/D105400
Bug 1476231 actually removed libav, so we don't build it, and don't need
neither the yasm check nor the LIBAV_FFT_ASFLAGS variable.
However, we still have checks, both in moz.build and code, for
MOZ_LIBAV_FFT, so we need to keep that.
Differential Revision: https://phabricator.services.mozilla.com/D105399
We don't hook it yet because `mach bootstrap` aborts early on arm64 right
now. And mach static analysis commands don't have enough information to
get the native toolchain.
Differential Revision: https://phabricator.services.mozilla.com/D105595
We've been building clang with SDK 10.12 since bug 1680152, but the
build-clang script is still assuming we're building with an older one.
Differential Revision: https://phabricator.services.mozilla.com/D105266
This will allow to upgrade the underlying docker image independently.
The resulting binary has been verified to be identical bit for bit.
Differential Revision: https://phabricator.services.mozilla.com/D105714
The WindowGlobalChild for a window will be null after it's been destroyed
(such as by a frame being removed), so we need to null check and fail safe.
Differential Revision: https://phabricator.services.mozilla.com/D106023
* onResourceListAvailable and populateStorageTree were both computing distinct dictinary. `storages` versus `this.storageResources` (with the resourcesWithHosts making them both differents). It is easier to follow if we have only one dictionary, build by onResourceListAvailable and that's the straight object given by the ResourceWatcher API.
* Since we migrated to resources API. `resources` object passed to onResourceAvailable
should no longer have any `from` attribute. This is no longer a RDP packet, but an array computed by the ResourceWatcher API.
* This isn't really useful to filter out resources with empty `hosts` because `populateTreeFromResource` will be a noop
if that's empty. I think it is easier to follow if we pass all the resources to this method.
Differential Revision: https://phabricator.services.mozilla.com/D105646
This variable name was confusing and didn't help understand the great complexity of this object.
This is a dictionary of storage resources, which also happen to be fronts, keyed by storage type/key (string).
Differential Revision: https://phabricator.services.mozilla.com/D105645
Resource updates and destroyed were ignored because the singleton storage resource
was cleaned on will-navigate.
So, we instead revert back to listen to events on fronts.
But instead of listening to a unique event on storageFront,
we listen to each individual storage resource front (one per type and per target).
This is why we have to do some filtering, still. Both on legacy listener and Watcher classes.
I'm also clarfifying things a bit in ContentProcessStorageWatcher,
I forked StorageActor completely, while removing its protocol.js Actor inheritance
and some stuff that we don't need for the Watcher class.
This help emitting stores-updated and stores-cleared and reuse the exact same
code between legacy listener and watcher class regarding filtering.
Differential Revision: https://phabricator.services.mozilla.com/D104687
jsreftest tests are staged into objdir, and specifying a path inside it isn't
user friendly.
Made it automatically try resolving the relative path from staged area, if
the relative path doesn't find any test.
Differential Revision: https://phabricator.services.mozilla.com/D106010
manifest[""] value is modified from filter string to [filter string, null]
array, in bug 1596567.
Updated the reftest.jsm side to follow the convension, and also added some
runtime check, to catch future change.
Differential Revision: https://phabricator.services.mozilla.com/D105996
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
