While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While processing third-party module loading events, the process may delayload
shlwapi.dll. This could be a problem if the process is sandboxed and the access
to local files is restricted. Before enabling the third-party modules ping in
socket process, this patch avoids such delayloading.
The first path is `ParamTraits<mozilla::ModuleRecord>::Read` calls `NS_NewLocalFile`
that calls `PathGetDriveNumberW`. This API is simple enough that we define our own
version.
The second path is the ctor of `ProcessedModuleLoadEvent` that is called from
`UntrustedModulesProcessor::CompleteProcessing` calls `PreparePathForTelemetry`
that calls `PathFindFileNameW` and `PathCanonicalizeW`. For this path, instead
of sanitizing a requested name in `ProcessedModuleLoadEvent`'s ctor, we sanitize
it when transferring it to the main process.
Differential Revision: https://phabricator.services.mozilla.com/D134492
We have a custom render node discovery code (needed for DMABUF) that
predates the `EGL_DRM_RENDER_NODE_FILE_EXT` extension. It has additional
value that it helps us discover the right vendor and device ID on
multi-GPU setups (there's a EGL extension far that backing, but
not ready yet).
In case our custom code fails - notably split display/render SoCs,
which are common in the ARM world - lets use
`EGL_DRM_RENDER_NODE_FILE_EXT` as fallback. This will ensure we
get a valid render node path on all devices, assuming the driver
supports that extension right. These SoCs are usually no multi-GPU
systems. If they are, we still don't get the right IDs - but an
extension for that is in the making.
Note: Mesa does *not* implement this right for such SoCs, i.e. it
will fail just as our own custom code. However, there's a MR in
review - once it lands, things should start working, see
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12796
Depends on D134254
Differential Revision: https://phabricator.services.mozilla.com/D134322
Mesa explicitly advertises the `EGL_MESA_device_software` extension
when appropriate. Only ever set `MESA_ACCELERATED` when that is the
case to avoid confusion around edge-cases and driver bugs.
The `EGL_MESA_device_software` extension is supported whenever
`eglQueryDeviceStringEXT` is. If the later is not supported, fall
back to GLX to make sure we continue detecting software drivers
on old Mesa versions. We don't want to enable EGL on such old drivers
anyway.
Note: this will break `glxtest` on the Wayland backend for old drivers.
This is not problem though as we don't ship it yet, don't plan to ship
it on old Mesa drivers and there don't seem to be any distributions
that ship such a combination (even RHEL 8 appears to ship newer Mesa
by now).
Differential Revision: https://phabricator.services.mozilla.com/D134254
`HeadlessShell.handleCmdLineArgs` needs to skip arguments starting with a hyphen
to search for a URL.
This patch also fixes a problem that `nsNativeAppSupportWin::CheckConsole` did
not remove processed command options.
Differential Revision: https://phabricator.services.mozilla.com/D132987
The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate `pingsender` to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the `backgroundupdate` task (and the test-only
`shouldprocessupdates` task).
Differential Revision: https://phabricator.services.mozilla.com/D133557
I've elected to rename the function from `Should...` to
`ShouldNot...`, but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.
This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133556
The aim is to avoid background tasks causing unexpected updates, as
happened when we tried to migrate `pingsender` to a Gecko background
task in Bug 1734262. This commit makes it so that we only process
updates for the `backgroundupdate` task (and the test-only
`shouldprocessupdates` task).
Differential Revision: https://phabricator.services.mozilla.com/D133557
I've elected to rename the function from `Should...` to
`ShouldNot...`, but not to rename the various test files. The
functionality under test is both "should" and "should not", so I think
the churn of renaming is not justified.
This rearranges the deck chairs to accommodate testing the new
functionality in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D133556
This is required to replace the existing MOZ_FORCE_ENABLE_FISSION environment
variables in environments which use that. In the future we'll want to stop
passing any environment variable when not passing a flag to `./mach run`
however that will require changes to the default test behaviour in bug 1744091.
Differential Revision: https://phabricator.services.mozilla.com/D133006
Unfortunately we currently always configure the "fission.autostart" pref when
running tests, meaning that the test_fission_autostart.py test is always being
skipped on all platforms. This change force-disables the required pref when
running the test, rather than skipping the test if it is set.
It would be nice to handle this in a less hacky way, but this was the first way
I could think of.
Differential Revision: https://phabricator.services.mozilla.com/D133005
The `-osint` flag is used as the signal that Windows is invoking
Firefox to handle a file type or protocol. The `-osint` flag was
introduced in order to mitigate security breaches due to poor argument
quoting (by consumers invoking Firefox); to use it for this new
purpose, it must be preserved for downstream consumers to react to.
Alternately, some marker of the flag could be maintained. Since the
flag needs to transit through the launcher process, I've elected to
simply not strip it as we validate command lines, and to accommodate
it further downstream. (It looks like Thunderbird already
accommodates `-osint`: see
https://searchfox.org/comm-central/rev/3e8f926de9ea09945b237177eb6d489c70318f0e/mail/components/MessengerContentHandler.jsm#568.)
The telemetry in this patch achieves two purposes. The first is to
count the number of times Firefox is invoked to handle a registered
file type or protocol: for this, a new keyed uint scalar was added.
File types start with a ".", just like on Windows; protocols
(equivalently, the schemes used to identify them) do not start with a
".".
The second is to identify times when Firefox is launched (i.e., it was
not already running) to handle a registered file type or protocol.
This generalizes the existing `os.environment.launch_method`,
introducing `os.environment.launched_to_handle` and
`os.environment.invoked_to_handle` string scalars, which record the
file type or protocol.
The command line state `STATE_INITIAL_LAUNCH` is used to discriminate
launching from invoking.
Differential Revision: https://phabricator.services.mozilla.com/D132288
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
This patch simply avoids calling SetAppID and SetCurrentProcessExplicitAppUserModelID when we're running from a packaged app. For `SetCurrentProcessExplicitAppUserModelID`, I ended up skipping the calls to the functions that call it because I thought it was less surprising behaviour given the names (eg: I might be surprised if `SetTaskbarGroupId` silently didn't set the taskbar group id). It's easy enough to switch up if skipping the calls at a lower level makes more sense.
I couldn't find any automated tests around the Jump List functionality (and we don't have any tests running within MSIX packages yet anyways...), but it worked just fine in my manual test. I also tested the scenario where the AppxManifest.xml ID changes during an upgrade (which will probably happen when https://bugzilla.mozilla.org/show_bug.cgi?id=1736113 gets done). This causes Jump Lists to stop working at first restart, but they appear to rebuilt after the usual few minute wait.
Differential Revision: https://phabricator.services.mozilla.com/D131693
We have the protection mechanism to protect `BaseThreadInitThunk`. After we
released the launcher process, however, this hook is activated if the launcher
process is disabled, or in plugin-container.exe. Hopefully this hook still
helps reduce the crash at `BaseThreadInitThunk`.
The patch moves the code applying the hook in `DllBlocklist_Initialize` to
make it run before the init flag check.
Differential Revision: https://phabricator.services.mozilla.com/D131673
Alexandre Lissy
Toshihito Kikuchi
Jan-Erik Rediger
Emilio Cobos Álvarez
Mike Hommey
Iulian Moraru
Cristian Tuns
Robert Mader
Marian-Vasile Laza
Nick Alexander
Butkovits Atila
Nika Layzell
Kirk Steuber
Sandor Molnar
Jonathan Watt
Chris Peterson
Ben Hearsum
Alexandru Michis