While ideally we'd just move all of them at the top-level, there are
other things that depend on them that wouldn't then get the right
dependencies. One of them is install steps in dist/something, but there
are others, and that's a rather long pole of things requiring many
changes along with chances to break things.
So instead, we go with a simpler and more limited approach, where we
still recurse into directories to run their export tier (to run whatever
else than GeneratedFiles they have), but ensure the GeneratedFiles we
moved at the top-level are built before recursing by making
directory/export depend on them.
Differential Revision: https://phabricator.services.mozilla.com/D80608
While currently the path given to the script is relative and doesn't
contain a directory, but will soon, and in that case, we don't want
the directory to be part of the const name (that wouldn't even be a
valid identifier).
Differential Revision: https://phabricator.services.mozilla.com/D80607
Ideally, this kind of manual work wouldn't be required, but the frontend
doesn't provide enough information and while backend could correlate the
information, they currently don't.
Differential Revision: https://phabricator.services.mozilla.com/D80606
While ideally we'd just move all of them at the top-level, there are
other things that depend on them that wouldn't then get the right
dependencies. One of them is install steps in dist/something, but there
are others, and that's a rather long pole of things requiring many
changes along with chances to break things.
So instead, we go with a simpler and more limited approach, where we
still recurse into directories to run their export tier (to run whatever
else than GeneratedFiles they have), but ensure the GeneratedFiles we
moved at the top-level are built before recursing by making
directory/export depend on them.
Differential Revision: https://phabricator.services.mozilla.com/D80608
While currently the path given to the script is relative and doesn't
contain a directory, but will soon, and in that case, we don't want
the directory to be part of the const name (that wouldn't even be a
valid identifier).
Differential Revision: https://phabricator.services.mozilla.com/D80607
Ideally, this kind of manual work wouldn't be required, but the frontend
doesn't provide enough information and while backend could correlate the
information, they currently don't.
Differential Revision: https://phabricator.services.mozilla.com/D80606
For performance reasons in SWGL software compositors. to avoid unnecessary
full-screen copies of the framembuffer, we need to allow those compositors to
map their underlying widget surfaces and pass that buffer to SWGL so that they
can be directly rendered to. That also requires supporting custom strides, as
we can't always enforce the particular layout of the buffers handed off to us.
To that end, InitDefaultFramebuffer is generalized to take such information
and then many places where we rely on a specific hard-coded SWGL-calculated
stride have been altered to deal with a caller-supplied stride.
Differential Revision: https://phabricator.services.mozilla.com/D80267
This class isn't used anymore, and it's safe to remove it.
We take this as an opportunity to remove Pool#cleanup and
Pool#isEmpty, which each only had one callsite.
Some comments are updated to not mention ActorPool.
Differential Revision: https://phabricator.services.mozilla.com/D80602
Remove pools and make target actors manage themselves.
devtools/server/tests/browser/browser_navigateEvents.js was modified
since the targetActor can't be retrieved with `searchAllConnectionsForActor`
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D67510
While the comment for 'GetFlatpakPortalEnv' said
"We use the same code as gtk_should_use_portal() to detect
if we're in flatpak env", this was not actually true, since the
code only checked whether the environment variable 'GTK_USE_PORTAL'
was set at all, ignoring its value, while the gtk implementation
checks that it is set and that the first character is '1'
(which was already true in the gtk as of the commit that the
comment refers to, [1]).
Adapt it to check for the actual value here, according to what
is also done at [2], so that setting 'GTK_USE_PORTAL=0' or
'GTK_USE_PORTAL=1' in the environment works as expected.
I ran into this while looking at why bug 1517074 still occured
with the native file chooser presumably having been disabled by
starting Firefox using
GTK_USE_PORTAL=0 firefox
with gtk 3.24.20 that does not yet have the fix for gtk issue [3].
[1] e0ce028c88/gtk/gtkprivate.c (L272)
[2] https://searchfox.org/mozilla-central/rev/37932bfc600f97ec923464086dc12cdaa72aefde/widget/gtk/nsFilePicker.cpp#608
[3] https://gitlab.gnome.org/GNOME/gtk/-/issues/1820
Differential Revision: https://phabricator.services.mozilla.com/D80073
